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1  SYSTEMS  LEVEL  DESIGN  SUMMARY 


1.1  CASTOR  OVERVIEW  (J.  JAMES  AND  J.  ROBINSON) 


This  design  document  describes  the  current  status  of  the  Cathode/ Anode  Satellite 
Thruster  for  Orbital  Repositioning  (CASTOR),  which  is  at  the  Critical  Design  Level. 

The  mission  of  CASTOR  is  to  validate  the  performance  and  application  of  Diverging 
Cusped  Field  Thruster  (DCFT)  technology.  The  mission  will  be  achieved  by  taking  on- 
orbit  state  data  to  compare  the  degradation  experienced  by  the  DCFT  to  that  of  similar 
technologies.  Specifically,  the  mission  objects,  with  corresponding  minimum  success 
criteria  are  shown  below: 


•  Operate  the  DCFT  on  orbit  for  1500  hours,  which  is  comparable  to  similar 
technologies 

•  Minimum  Success:  Demonstrate  that  the  DCFT  will  operate  on-orbit 

•  Measure  the  on-orbit  performance,  efficiency,  and  degradation  of  the  DCFT 
during  orbital  maneuvers 

•  Minimum  Success:  Use  the  DCFT  to  provide  a  measurable  change  in 
velocity 


1.2  UNIVERSITY  NANOSAT  PROGRAM  (UNP)  (C.  CROWELL) 


The  CASTOR  satellite  is  being  designed  with  the  support  of  the  AFOSR  University  Nanosat 
Program  (UNP)  and  the  Air  Force  Research  Lab  Space  Vehicles  Directorate  (AFRL/RV). 
The  UNP  office  provides  support  in  terms  of  expert  telecons,  design  reviews,  workshops, 
funding,  and  a  sponsorship  for  a  launch  (through  the  Space  Test  ProgranTs  (STP‘s)  SERB 
process)  to  the  winning  university.  MIT  is  one  of  1 1  universities  participating  in  UNP-6.  The 
UNP  competition  began  in  January  2009  and  will  conclude  in  January  2011.  Inside  of  these 
terms,  the  UNP  timeline  includes  the  following  major  design  reviews: 

•  SCR  -  Systems  Concept  Review  (March  2009  via  Telecon) 

•  SRR  -  Systems  Requirement  Review  (April  2009  via  Telecon) 

•  PDR  -  Preliminary  Design  Review  (August  2009,  Logan,  UT) 

•  CDR  -  Critical  Design  Review  (April  2010,  MIT) 

•  PQR  -  Proto-Qualification  Review  (August  2010,  Logan,  UT) 

•  FCR  -  Flight  Competition  Review  (January  2011,  Albuquerque,  NM) 

At  FCR,  each  university  will  have  a  15  minute  presentation  and  then  a  hardware  station 
afterwards  and  groups  of  judges  will  evaluate  the  final  design  and  choose  the  winner.  All 
previous  reviews  can  be  found  in  section  4.2  in  the  fileshare.  Additional  UNP  activities 
include  the  Student  Hands-on  Training  (SHOT)  workshops  in  the  summer  of  2009  and  2010 
at  the  University  of  Colorado-Boulder.  This  consisted  of  building  a  small  payload  for  a  high 
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altitude  balloon  flight.  Another  UNP  event  is  the  fabrication  class,  which  occurred  in  January 
2010  at  Rutland  AFB,  NM.  UNP  provided  resources,  expertise,  and  experience  for  the 
design  of  CASTOR.  Additionally,  the  UNP  User‘s  Guide  outlines  several  requirements  and 
guidelines  that  the  satellite  needs  to  be  built  to.  Any  departure  from  the  requirements  outlined 
by  the  UNP  office  will  require  waivers  to  be  submitted  and  approved. 

1.3  OVERALL  ARCHITECTURE  (J.  JAMES  AND  R.  MCLINKO) 

Eight  subsystems  comprise  the  satellite.  These  are  Power,  Propulsion,  Science  and 
Payload,  ADCS,  Communication,  Avionics,  Structures,  and  Thermal.  Each  subsystem 
has  a  team  of  students  who  work  on  improving  and  testing  that  system.  A  ninth  team, 
known  as  the  Systems  team,  acts  to  unify  the  subsystems. 


1.3.1  APPROACH 


The  Systems  team  is  responsible  for  determining  the  overall  architecture  of  the  CASTOR 
system.  The  optimal  shape,  size,  mass,  and  other  driving  factors  of  the  spacecraft  are 
determined  from  the  University  Nanosatellite  Program  guidelines,  the  16.83  designs  of 
the  subteams,  UNP  PDR  and  CDR  feedback,  and  constraints  provided  by  the  faculty. 
Furthermore,  as  it  becomes  necessary  to  decide  between  two  conflicting  subsystem 
choices,  the  Systems  team  is  responsible  for  negotiating  a  solution  between  the 
conflicting  subsystems.  The  design  presented  below  is  the  current  architecture  of 
CASTOR. 


1.3.2  CURRENT  ARCHITECTURE 

Figure  1.3-1  shows  the  overall  structure.  A  central  propellant  tank  is  surrounded  by 
structural  trusses  to  which  CASTOR’S  other  components  are  mounted.  The  spacecraft  is 
then  mounted  with  the  ESPA  ring  to  the  fore  end  of  the  spacecraft  (inside  for  launch 
configuration)  and  attached  inside  a  volume  that  marginally  exceeds  UNP  constraints 
(allowing  for  a  50  cm  x  50  cm  x  60  cm  satellite).  The  maximum  wet  mass  of  the  satellite 
is  50  kg,  meeting  UNP  mass  constraints. 
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FIGURE  1.3-1:  CONFIGURATION  (DEPLOYED)  WITH  MASS  MOCKUPS 


Subsystem  architectures  for  the  current  system  are  outlined  below: 

•  Structures:  Four  trusses  mount  around  the  propellant  tank  using  three  tank 
clamps.  The  ESPA  ring  mount  attaches  to  the  bottom  of  the  trusses;  two  of  the 
solar  array  panels  are  body-mounted  directly  to  the  trusses,  and  the  other  two 
solar  panels  mount  to  opposing  trusses  with  a  hinge.  The  solar  arrays  deploy 
using  linear  actuators  that  release  pins  in  the  panels. 

•  Thermal:  A  number  of  components  require  surface  treatments  of  Z93  (a 
white  paint)  in  order  to  maintain  operational  temperatures.  Temperature 
sensors  will  also  be  used  to  track  the  thermal  state  of  the  satellite,  though 
passive  control  shall  be  the  primary  mode  of  operation. 

•  Operations:  The  HETE  ground  station  at  Cayenne  will  be  used.  Pre-launch 
and  launch  operations  are  compiled  in  the  Concept  of  Operations  Document 
(ConOps).  The  on-orbit  operations  will  be  performed  as  follows:  detumble, 
solar  panel  deployment,  commissioning,  system  verification  (standard  orbit 
operations),  decommissioning,  and  finally  end  of  life  via  uncontrolled  re¬ 
entry.  Orbital  maneuvers  will  be  performed  in  LEO  to  demonstrate  high 
delta- v  capability  via  orbital  altitude  changes. 

•  ADCS:  Attitude  determination  will  be  performed  with  four  Sinclair  sun 
sensors,  two  PNI  Corporation  3-axis  magnetometers,  and  a  3-axis  gyro. 
Attitude  control  will  be  performed  with  three  reaction  wheel  assemblies  in 
each  orthogonal  thrust  axis  and  three  torque  coils  in  each  orthogonal  axis. 

GPS  navigation  will  be  used  for  GNC  using  a  space-rated  SSTL  GPS  receiver. 
Furthermore,  a  NORAD  TLE  is  provided  for  free  on  a  daily  basis  for  a  cross 
check.  Furthermore,  a  magnet  will  be  placed  opposite  the  engine  to  cancel  the 
engine  dipole. 

•  Avionics:  The  backbone  of  the  avionics  subsystem  consists  of  three 
Microchip  dsPIC33F  16-bit  microcontrollers  and  a  FLASH  memory  device. 
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These  components  are  accompanied  by  sensors  and  actuators,  while  running 
FreeRTOS. 

•  Communications:  Two  Microhard  S-band  modems  will  support  two  patch 
antennas  to  provide  115  Kbps  data  rate  capability. 

•  Propulsion:  A  modified  field  thruster  built  in-house  will  operate  in  either 
high  power  mode,  providing  about  4  mN  of  thrust,  or  in  off  mode,  in  which 
the  cathode  will  remain  heated.  The  propulsion  system  will  also  consist  of  the 
tank  and  various  plumbing  components.  The  thruster  will  be  mounted  on  the 
opposite  end  from  the  ESPA  ring  mount.  Plumbing  will  be  provided  largely 
by  a  NASA-provided  flow  controller,  the  Xenon  Feed  System  (XFS). 

9 

•  Power:  Donated  Foral  cells  with  an  area  of  1.1  nr  will  provide  a  maximum  of 
160  W  to  the  Maximum  Peak  Power  Tracker,  which  will  provide  power  to  the 
various  components  as  needed  and  to  Nickel-Cadmium  batteries  for  storage 
during  eclipse.  Furthermore,  in-house  assembled  Power  Processing  Unit  and 
Power  Distribution  Unit  will  provide  power  to  propulsion  and  all  other 
systems,  respectively. 

•  Science  and  Payload:  A  camera  pointed  at  the  cathode  and  thruster  provides 
critical  information  on  degradation  of  the  thruster  and  performance  of  the 
cathode  during  the  firing  phase.  A  shutter  protects  the  lens  from  damage 
when  the  camera  is  not  taking  photos.  The  color  of  the  plume  in  the  image 
provides  information  on  thruster  efficiency. 


1.4  MISSION  REQUIREMENTS  (K.  ANDERSON) 


CASTOR’S  requirement  verification  matrix  (RVM)  provides  the  list  of  requirements  that 
CASTOR  needs  to  fulfill  and  which  provide  direction  when  deciding  upon  a  design.  In 
addition  to  this  function,  the  RVM  provides  an  understanding  between  all  parties 
involved,  mainly  the  CASTOR  group  and  UNP,  of  what  exactly  the  satellite  will  do. 

The  requirements  come  from  UNP  guideline,  interfacing  requirements,  or  requirements 
needed  in  order  to  fulfill  the  mission  statement.  The  requirements  that  originate  from  the 
mission  statement  should  carry  through  all  of  the  subsystems  to  allow  for  requirement 
traceability  and  ensure  that  the  overarching  requirements  are  met  by  all  the  smaller  more 
detailed  requirements  that  it  encompasses. 

The  mission  requirements  are  stated  as  follows: 

•  Measure  the  on-orbit  performance,  efficiency,  and  degradation  of  the  DCFT 
during  orbital  maneuvers 

•  Operate  the  DCFT  simultaneously  in  the  operational  space  environment  and  a 
vacuum  chamber 

The  system  requirements  stem  from  the  mission  requirements  and  are  stated  as  follows: 
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•  CASTOR  shall  have  a  DCFT  as  the  primary  propulsion  system,  which  shall 
operate  throughout  the  mission  lifetime 

•  The  CASTOR  bus  must  be  able  to  support  on-orbit  mission  operations  for  the 
mission  lifetime  of  at  least  6  months 

•  CASTOR  shall  provide  sufficient  state  data  to  measure  the  change  of 
performance,  efficiency,  and  degradation  over  the  DCFT's  operational  lifetime 

In  addition  to  stating  each  of  the  requirements,  the  requirements  verification  matrix  lists 
the  document  that  shows  how  that  requirement  was  met  and  the  test  that  verified  it  was 
met.  For  instance,  the  requirement:  “EPS  must  be  able  to  generate  1 13.7W  in  a  fully 
operational  state”;  is  met  in  the  Design  Documentation  and  tested  in  the  solar  panel  test. 

The  requirements  verification  matrix  also  states  the  status  of  meeting  a  particular 
requirement.  If  the  satellite  has  been  designed  in  a  way  that  the  requirement  should  be 
met,  and  not  tested  it  is  yellow.  If  it  has  been  tested  and  verified  it  is  green.  If  it  hasn't 
been  designed  or  the  current  design  doesn’t  meet  the  requirement,  the  column  is  red.  The 
RVM  currently  is  all  green  and  yellow  meaning  that  the  current  design  meets  all  of  the 
requirements,  but  hasn’t  been  fully  verified,  the  appropriate  status  for  CDR. 

The  RVM  has  all  of  the  requirements  listed,  and  each  of  these  requirements  is  met 
through  the  design.  All  of  the  requirements  have  a  verification  document  listed,  and  the 
tests  that  have  been  performed  and  the  results  have  been  written,  the  entire  requirement 
row  is  filled.  The  RVM  is  listed  in  Appendix  Error!  Reference  source  not  found.. 

1.5  TEAM  ORGANIZATION  (J.  JAMES) 

In  order  to  allow  specialization,  work  on  CASTOR  is  divided  into  teams.  The 
organizational  structure  of  teams  shown  in  Figure  1.5-1  allows  for  the  efficient  flow  of 
information  between  these  subsystems.  The  chart  outlines  the  Spring  2010  personnel  as 
well  as  indicating  their  involvement  in  various  teams.  Lines  linking  the  members  of  the 
Systems  Team  to  sub-teams  show  how  systems  members  act  as  liaisons  to  the  various 
teams. 
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FIGURE  1.5-1:  CASTOR  ORGANIZATION 


Figure  1.5-1  highlights  the  nine  CASTOR  sub-systems.  These  teams  specialize  in 
various  technical  aspects  of  the  project.  The  Systems  team,  consisting  of  four  primary 
members,  provides  the  leading  management  and  system  interfacing.  Additionally,  each 
member  of  the  Systems  team  acts  as  a  liaison  to  two  sub-teams  (illustrated  in  Figure  1.5-1 
by  a  connecting  line).  Each  sub-team  has  a  team  lead  (shown  in  bold),  who  is  held 
responsible  for  the  deliverables  for  that  team.  Both  students  enrolled  in  16.83  and 
UROPs  are  included  in  this  diagram.  Ten  graduate  students  and  eight  faculty  and  staff 
are  spread  among  the  teams  providing  continual  mentorship.  Organizational  structure 
allows  efficient  flow  of  information  from  the  systems  team  down  to  subsystem  team,  and 
from  subsystems  directly  to  the  systems  team  which  can  call  all  subsystems  to  action. 
Communication  between  subsystems  is  facilitated  during  weekly  team  leads  meetings 
(with  the  systems  team)  where  inter-team  issues  are  addressed.  Subsystems  are  also 
encouraged  to  work  directly  with  other  subsystems  on  relevant  tasks. 
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1.6  BUDGET  (G.  FRITZ) 


1.6.1  APPROACH 

The  Systems  team  is  responsible  for  tracking  CASTOR’S  mass  and  cost  budget.  The  goal 
with  this  tracking  is  to  ensure  that  every  team  is  aware  of  the  current  state  of  the  satellite 
and  how  much  funding  is  still  available  for  purchasing  and  manufacturing. 


1.6.2  ORGANIZATION 


The  cost  and  mass  budgets  for  CASTOR  are  tracked  through  the  use  of  the  Master 
Equipment  List  or  MEL.  This  list  is  an  Excel  Spreadsheet  documenting  is  component 
either  on  the  flight  model  of  the  satellite  or  used  for  testing.  It  also  tracks  components 
that  still  need  to  be  acquired. 

Each  subteam  has  a  section  of  the  MEL  dedicated  to  them.  Through  regular  meetings 
with  Systems  and  the  team  leads,  the  MEL  is  always  an  up  to  date  representation  of  the 
components  on  the  satellite.  When  any  component  is  updated  on  the  MEL  the  person 
responsible  for  the  change  will  document  his  name  and  the  date  onto  that  component’s 
row  so  that  others  can  verify  the  change  in  the  future.  Each  team  can  use  the  MEL  to 
identify  particular  part  numbers  or  types  of  components  used  by  other  teams  should  they 
need  to  interface  with  them  in  their  designs. 

Due  to  the  high  density  of  presentations  over  the  past  few  months,  the  MEL  has  been 
equipped  with  the  functionality  of  rapidly  and  easily  producing  charts  and  tables  to 
represent  the  components  on  the  list  on  a  team-by-team  basis.  The  new  tab  labeled 
“Graphs  and  Tables”  only  requires  the  user  input  of  changing  a  drop  down  box  to 
represent  the  appropriate  team  and  the  table  and  graph  will  automatically  update.  This 
will  continue  to  be  a  useful  tool  as  CASTOR  moves  forward  to  document  and  present  the 
data. 

The  MEL  has  the  ability  to  hold  independent  margins  for  both  cost  and  mass  for  every 
component  listed.  This  allows  greater  flexibility  and  accuracy  when  margining 
components  since  there  may  be  better  knowledge  on  one  characteristic  over  the  other. 

For  example,  a  part  may  have  been  bought,  so  cost  is  exact,  but  the  component  has  not 
yet  been  received  and  measured  in  the  lab,  so  mass  and  power  are  estimates.  The 
margining  scheme  is: 

Exact  (0-5%) 

Mass:  component  has  been  weighed  and  integrated  into  the  satellite 

Cost:  component  has  been  purchased 

Fine  Estimate  (5%-10%) 
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The  mass  or  cost  has  been  quoted  by  the  manufacturer  or  found  on  a 
specification  sheet. 

Coarse  Estimate  (15%  -  35%) 

Number  based  on  SMAD  or  other  approximation  not  yet  verified  by 
manufacturer. 

Guess  (35%  +) 

The  component  is  still  largely  unknown,  such  as  bolts/nuts  in  the  current 

design. 


1.6.3  BUDGET  TRACKING 


Systems  with  the  assistance  of  G.  Sondecker  also  tracks  the  purchase  orders  that 
Professor  Bauer  receives  and  updates  the  MEL  part  status  to  “delivered”.  Furthermore,  all 
purchases  must  be  approved  by  G.  Sondecker  and  (for  purchases  over  $100)  R.  McLinko 
before  being  submitted  to  Paul  Bauer.  Purchases  are  approved  only  if  the  component  is 
listed  on  the  MEL. 

The  accrued  costs  of  all  purchased  items  are  being  tracked,  not  just  those  of  flight 
hardware.  An  item  is  added  to  the  spending  tracking  sheet  once  the  purchase  order  has 
been  approved,  not  when  the  actual  debt  has  been  incurred.  This  will  allow  the  team  to 
anticipate  the  need  to  request  more  funding  in  a  timely  manner,  should  it  become 
necessary.  Purchase  orders  must  be  approved  by  the  Systems  team  in  order  to  prevent 
unauthorized  purchases.  A  student  who  wishes  to  purchase  hardware  must  completely  fill 
out  a  standardized  Purchase  Order  or  PO  form.  This  PO  is  then  sent  to  G.  Sondecker, 
who  then  checks  the  MEL  to  verify  the  part  is  accounted  for.  If  it  is,  then  the  PO  is 
submitted  to  Paul  Bauer  for  purchasing.  If  the  part  is  not  accounted  for  in  the  MEL,  then 
it  must  first  be  submitted  for  approval  to  the  MEL  before  being  approved  for  purchase.  If 
it  is  subsequently  added  to  the  MEL,  the  PO  will  then  be  accepted. 

This  past  March  each  subteam  provided  a  list  of  components  that  still  need  to  be 
purchased  before  FCR  next  January.  An  estimated  $101,108.64  of  hardware  and  test 
expenditures  is  anticipated  through  FCR. 


1.6.4  BUDGET  ALLOCATIONS 


The  Systems  team  uses  the  allocations  assigned  to  subsystems  to  hold  them  accountable 
for  their  budgets.  Allocations  were  initially  defined  based  on  the  preliminary  design 
developed  in  spring  2008  during  the  first  16.83x  sequence.  These  allocations  have  been 
constantly  updated  by  Systems  to  allow  the  design  to  move  forward.  Since  the  design  has 
been  actively  holding  the  margined  mass  constraint  of  50  kg,  providing  additional 
allocation  to  one  team  always  meant  removing  allocation  from  another.  As  such,  the 
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Systems  team  often  had  to  manage  trade  studies  between  subteams  and  negotiate  the 
latest  allocations  and  resulting  architecture.  At  this  point  in  the  program,  final  allocation 
changes  are  being  determined  toward  the  final  design.  As  such,  the  masses  between 
subteams  are  relatively  solid  and  there  has  been  very  little  fluctuation  this  term. 


1.6.5  CURRENT  BUDGET 


A  summary  of  the  current  budget  is  shown  in  Table  1.6-1. 


Mass  (Kg) 

Margined  Mass 
(Kg) 

Cost 

Margined 

Cost 

ACS  &  GNC 

1.91 

2.21 

$132,850.00 

$148,236.00 

Avionics 

2.59 

3.83 

$  23,010.00 

$  25,311.00 

Communications 

0.36 

0.43 

$  1,255.80 

$  1,400.96 

Propulsion 

12.23 

13.09 

$  1,702.00 

$  1,794.60 

Power 

9.41 

10.10 

$  39,644.50 

$  43,928.95 

Thermal 

0.34 

0.38 

$  4,267.18 

$  4,750.18 

Structures 

16.70 

19.36 

$  1,473.18 

$  1,911.65 

Science  and  Payload 

0.10 

0.13 

$  7,926.33 

$  8,865.21 

Total 

43.62 

49.54 

$212,128.99 

$236,198.54 

TABLE  1.6-1:  CURRENT  BUDGET 


As  is  evident  from  the  table,  the  current  CASTOR  design  is  at  the  margined  mass 
constraint  and  within  the  margined  cost  constraint. 


1.7  SCHEDULE  (G.  FRITZ) 


Due  to  the  segment  sub-team  structure  of  the  CASTOR  project  it  is  important  to  track 
progress  among  individual  teams.  Scheduling  is  a  constantly  evolving  process  with  each 
team  developing  goals  and  action  items,  submitting  them  to  Systems  and  then  getting 
feedback.  This  back  and  forth  of  checking  scheduling  allows  for  a  cohesive  structure  that 
spans  all  teams  and  enhances  accountability  among  the  teams. 

A  representation  of  the  flow  of  schedule  tracking  as  it  is  done  at  CASTOR  is  represented 
by  Figure  1.7-1. 
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FIGURE  1.7-1:  SCHEDULING  FLOW  CHART 

The  Systems  team  is  currently  operating  in  the  last  two  bubbles  of  the  flow  chart.  There 
has  been  a  recent  update  to  the  schedule  conducted  in  March  where  all  predecessor  tasks 
have  been  identified  at  a  team  leads  meeting.  Now  that  critical  paths  have  been 
identified,  Systems  now  needs  to  ensure  that  deadlines  are  being  met,  and  if  they  are 
subject  to  schedule  slip,  re  allocate  personnel  to  help  meet  the  deadline. 

The  current  schedule  takes  form  of  a  Gantt  chart  developed  as  a  Microsoft  Project.  This 
full  schedule  can  be  found  under  section  1.1  of  the  fileshare  [1].  The  basic  organization 
of  the  chart  is  by  each  team  sub  ordered  by  start  date.  The  arrows  connecting  tasks  to 
each  other  represent  tasks  that  require  completion  of  a  previous  task  before  they  can 
begin.  These  are  particularly  important  for  the  Systems  team  to  monitor  if  a  predecessor 
task  is  going  to  slip  schedule  and  what  tasks  will  be  effected  by  that.  Checks  for  schedule 
slip  occur  at  each  team  leads  meeting. 


1.8  INTERFACE  CONTROL  DOCUMENTS  (A.  FUHRMANN) 


The  purpose  of  an  ICD  is  to  document  and  explain  all  of  the  possible  inputs  to  and  all 
potential  outputs  from  a  system  or  subsystem.  This  documentation  is  helpful  not  only  for 
the  future  user  of  the  system,  but  also  for  each  sub  team  designing  the  system.  These 
documents  help  the  designers  determine  what  information  they  need  to  request  from  each 
team  as  well  as  how  their  design  changes  may  affect  the  other  teams. 
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Below  is  a  template  for  the  MIT  format  ICD  as  well  as  explanations  for  each  component. 
Formatting  is  often  times  just  as  important  as  the  technical  content  because  improper 
formatting  can  easily  make  the  technical  message  confusing  or  completely  not 
interpretable. 


The  title  page  gives 
basic  information  such 
as  which  two 
components  are  being 
discussed. 

It  may  also  have 
instructions  for 
distribution  of  the 
information  contained  in 
this  document. 


Make  sure  the  table  of 
contents  is  correct. 

ICDs  are  updated 
frequently  and  pages  are 
constantly  shifting. 

List  all  of  the  figures 
and  tables  as  well  as 
their  locations  for  quick  . 
reference 

While  ICD  is  being 
created  there  will  be 
many  TBR  and  TBDs 
during  the  system 
design  process. 

Explicitly  document 
these  so  that  they  will 
not  be  overlooked  later 


Rev  Date:  29080914 


Massachusetts  Institute  of  Technology  16.83x 
Lunar  Express 
TSD  to  TBD  Data  Interface 
Interface  Control  Document 


The  publication  of  tbis  material  does  not  constitute  approval  by  the  lfi.SSx  program 
conclusion  herein.  Wide  distribution  or  announcemsatt  of  this  material  shall  not  be  i 
specific  approval  of  the  16.83x  program. 

Distribution  limited  to  K.S-xprogram  members,  associated  revigwen,  and  their  co: 
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1  Scope . . . . . 

2  Applicable  documents 
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IF  ACE  A  to  IF  ACE  B 
|L1  1  ICD  Bloch  Diagrem 
1  1  2  Connector  Pin  On  In  Mena 
3.1.3  Software  Protocol 

3  1  «  Data  Load  . 

Notes 

4.1  Definitions  Ac  rossvms 


Figure  3-1,  SCP  Interne e  Bloch  Diagram 


Table  3-1,  SCP  In 


Table  of  Tables 


TBRs/TBDs 

Whs:  numbers  or  interfaces  are  simply  estimates  that 
Reviewed  (TBR).  When  numbers  or  intet 
To  Be  Determined  (TBD). 

Numbers  and  interfaces  that  are  TBR  TBD  are  summarized  in  the  table  below: 


Section(s) 


Description 
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1  Scope 

Thii  ICD  establishes  the  detailed  design  criteria  for  the  in 
nomeatdature)  and  the  (insert  nomenclature)  items. 

2  Applicable  documents 

[Reference  XSL  STDs .  Working  .1 Sass  and  Pov 
documents  as  necessary] 

3  Interface  Definition 

3.1  IFACEA  to  IFACE  B 


3.1.1  1C  D  Block  Diagram 


and  other  controlling 


3.1.2  ConnectorPin  Out/In  Matrix 

[Preside  a  wile,  similar  so  the  example  belov  uith  connectors  &  associated  information. 
Shielded  svistedpair :  braided  coadal.  terminated  impedance,  esc...  Ensure  pin  for  pin 
matchviihthe  specification  forthe  assemblies  or  subsystems  inquestion.] 


The  signature  page 
needs  to  have  the  names 
of  key  persons  relevant 
to  this  document. 

These  people  may  be  the 
relevant  subsystem  team 
leads,  systems  lead, 
chief  engineer,  etc. 


The  Scope  section 
should  be  a  relatively 
short  description  of 
what  systems  this  ICD 
covers 

Applicable  Documents 
are  important  to  point 
out  especially  if  the 
expected  audience  is  not 
familiar  with  them  or  do 
not  have  explicit  access 
to  the  reference 
documents 

ICD  block  diagrams 
should  be  an  extremely 
simple,  non-technical 
diagram  which 
eliminates  any 
ambiguity  about  what 
system  interfaces  are 
being  discussed. 
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Document  all  changes 
so  that  everyone 
working  on  the  ICD 
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The  specific  sections  of 
the  ICD  will  be  different 
for  each  type  of 
subsystem.  For 
example,  avionics  will 
have  a  section  for 
Software  Protocol  while 
the  Structures  team 
would  have  no  need  for 
that  section 
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Software  Protocol 


3.1.4  Data  Load 

[Describe  she  data  thatvill  be  passed  through  this  interface  ] 
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4  Notes 

4.1  Definitions/Acronyms 

[Pioce  off  definitions  or  unfamiliar  acronyms  h 


5  Appendix 

5.1  Scope 

[Jep  additional  drautngs  or  clarifying  remarks  should  reside  he 


RyanMd-into 


FIGURE  1.8-1:  ICD  EXAMPLE 


ICD  Management 

Storage:  The  ICDs  which  are  available  for  editing  by  the  subteams  are  stored  in  the 
CASTOR  fileshare  under  2.2-Interfaces_Management  [2].  This  is  where  the  sub  teams 
can  view  their  ICDs  and  make  changes  as  they  see  fit.  When  they  sub-teams  want  to 
submit  these  changed  ICDs  for  approval  they  send  them  to  their  system  liaison.  We  do 
an  initial  screening  of  the  ICDs  as  well  as  pass  them  on  to  TAs  who  can  point  out 
mistakes  we  may  have  missed.  Once  the  inconsistencies  have  been  fixed,  the  ICDs  are 
then  placed  in  the  UNP  section  under  4.2.4.2-Documenation-ICDs  which  will  eventually 
be  submitted  to  UNP. 


Subteam  edits 
ICD 


Systems  Graduate  TAs  provide 

Reviews  ICD  feedback  on  ICD 


Systems 
commits  ICD 
to  fileshare 


FIGURE  1.8-2:  ICD  MANAGEMENT  FLOW 
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Tracking  Changes:  When  an  ICD  is  edited  the  author  needs  to  list  the  date  of  change  as 
well  as  the  topic  of  change  in  the  “Revision  History”  section  of  the  ICD  itself.  This  way, 
when  the  document  is  reviewed,  any  questions  can  be  directed  to  the  original  author. 

This  facilitates  ease  and  speed  of  the  ICD  change  approval  process. 

Types  of  ICDs 

The  Mechanical  ICD  identifies  the  hardware  for  the  system  or  subsystem,  and  identifies 
to  what  it  will  be  connected.  For  each  piece  of  hardware,  the  ICD  contains  three  main 
subsections:  ICD  Block  Diagram,  Physical  Envelopes,  and  Hardware  Mounting.  The  ICD 
Block  Diagram  identifies  and  shows  all  critical  interfaces  for  the  item.  The  Physical 
Envelopes  section  gives  the  initial  (and,  if  applicable,  final)  current  best  estimate 
dimensions  of  the  item:  length,  width,  height,  volume,  and  mass.  The  Hardware 
Mounting  section  provides  a  CAD  drawing  (if  applicable)  of  each  item,  and  describes  the 
surface  location,  the  hole  locations,  and  the  mounting  hardware  to  be  used.  For  many 
pieces  of  hardware,  a  fourth  subsection,  modeling,  is  included;  this  section  describes  any 
analysis  (e.g.  CAD  drawings,  finite  element  analysis)  that  was  used. 

The  Power  ICD  identifies  the  hardware  necessary  to  power  each  system  or  subsystem, 
and  identifies  to  what  the  hardware  will  be  connected.  The  ICD  contains  four 
subsections:  ICD  Block  Diagram,  Connector  Pin  Out/In  Matrix,  Grounding,  and  Load. 
The  ICD  Block  Diagram  identifies  and  shows  all  interfaces  and  connections  for  the 
hardware.  The  Connector  Pin  Out/In  Matrix  lists  the  in  and  out  pins  used  for  each 
connection,  as  well  as  the  amount  of  amperage  passing  through  the  connections. 

Diagrams  of  the  pin  connections  are  included.  The  Grounding  section  identifies  the  type 
of  grounding  connections  (i.e.  analog,  digital,  or  both).  The  Load  section  identifies  the 
amount  of  power  each  piece  of  hardware  will  receive  during  the  mission,  and  how  often 
the  power  will  be  received. 

The  Thermal  ICD  identifies  the  surface  connections  (i.e.  metal  on  metal  contact)  for  each 
system  or  subsystem.  The  ICD  contains  four  subsections:  ICD  Block  Diagram,  Heat 
Transfer  Method,  Thermal  Path,  Heat  Loads  and  Fluxes,  and  Modeling.  The  ICD  Block 
Diagram  identifies  the  connections  between  the  surfaces.  The  Heat  Transfer  Method 
section  defines  the  method  of  heat  transfer  that  will  take  place,  the  Thermal  Path  section 
identifies  the  path  the  heat  load  will  travel,  and  the  Heat  Loads  and  Fluxes  section 
identifies  the  amount  of  heat  load  that  will  be  transferred  during  the  mission,  as  well  as 
the  hardware  limits.  The  Modeling  section  lists  the  types  of  analyses  used. 

The  Data  ICD  identifies  the  hardware  for  each  subsystem  and  to  what  it  will  be 
connected.  For  each  piece  of  hardware,  the  ICD  contains  four  sections:  ICD  Block 
Diagram,  Connector  Pin  Out/In  Matrix,  Software  Protocol,  and  Data  Load.  The  ICD 
Block  Diagram  shows  all  interfaces  and  connections  between  the  hardware.  The 
Connector  Pin  Out/In  Matrix  lists  the  physical  pin  or  socket  connections  for  each  piece  of 
hardware,  and  whether  the  connection  is  in  or  out,  as  well  as  the  voltage  and  amperage  of 
each  connection.  The  Software  Protocol  section  describes  how  the  software  will  interact 
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with  the  hardware,  and  the  Data  Load  section  lists  the  type  and  amount  of  data  that  will 
flow  between  the  hardware,  and  how  often,  during  the  mission. 

Interface  Diagram 

The  following  diagram  provides  a  visual  representation  of  the  relationships  between  all  of 
the  subteams  and  the  subsequent  ICDs  which  need  to  be  managed  for  each  relationship. 


Pre-Launch  Interface  Diagram 


FIGURE  1.8-3:  PRE-LAUNCH  INTERFACE  DIAGRAM 


1.9  RISK  MANAGEMENT  (J. JAMES) 


In  order  to  mitigate  risk,  potential  difficulties  must  be  identified,  quantified,  tracked  and 
analyzed.  A  risk  tracking  spreadsheet  serves  as  the  backbone  of  CASTOR’s  risk 
management  system.  Risk  factors  require  continuous  monitoring  and  thorough  analysis 
for  the  purpose  of  risk  reduction. 


1.9.1  DEFINING  RISK 
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Risk:  The  inability  to  achieve  mission  objectives  -  comprised  of  failure  probability  and 
consequences. 

There  are  several  types  of  risk.  In  order  to  consider  them,  a  careful  definition  was 
determined  by  consulting  NASA,  Air  Force,  and  MIT  documentation  [3].  Programmatic 
risk  consists  of  any  risk  involving  the  program,  including  all  external  and  internal  risk. 
Subsets  of  programmatic  risk  include  technical  risk,  cost  risk,  and  schedule  risk. 

Tradeoffs  between  the  types  of  risk  constitute  risk  management.  Risks  differ  from  issues 
in  that  they  are  problems  that  have  not  yet  occurred.  Once  a  risk  becomes  a  reality,  it  is 
an  issue  and  requires  immediate  action. 

Successful  risk  management  comes  from  continuous  work.  In  order  to  mitigate  risk, 
careful  identification,  analysis  and  tracking  must  be  completed  to  ensure  safety.  The 
management  process  can  be  broken  into  four  stages  -  planning,  assessment,  handling  and 
monitoring. 

Risk  planning  involves  creating  a  framework  to  identify  and  track  risks,  along  with  their 
mitigation  strategies.  Documentation,  such  as  the  risk  management  file  currently  on  the 
fileshare,  falls  under  this  category  [4].  Planning  also  includes  scheduled  meetings  with 
team  leads  to  discuss  risks. 

Assessment  consists  of  the  actual  identification  and  analysis  of  risks,  including  their 
likelihood  and  perceived  consequence.  Assessments  are  generally  conducted  by 
subsystem  personnel,  at  the  request  of  risk  management  managers.  Updating  the 
documentation  created  in  the  planning  stage  is  a  part  of  assessment. 

Risk  handling  is  the  response  to  risk  assessment.  Operational  backup  plans  fall  into  the 
category  of  handling.  Risk  handling  also  involves  distribution  of  responsibility  of  risk 
mitigation,  to  team  leads  for  instances,  as  well  as  a  plan  forward  to  reduce  or  respond  to 
risks.  .  Higher  risk  items  shall  be  brought  to  the  attention  of  everyone  in  the  systems 
team  to  increase  involvement.  Assessment  also  involves  assigning  a  value  to  risks.  For 
CASTOR,  the  current  metric  is  risk  level ,  measured  as  a  function  of  likelihood  and 
consequence.  Each  risk  item  receives  a  score  from  1-5  for  both  likelihood  and  severity  of 
consequence  (5  being  extremely  likely  or  catastrophic).  The  risk  level  is  low  (green), 
medium  (yellow),  or  high  (red). 

Finally,  risk  monitoring  is  the  process  by  which  the  entire  system  risk  is  checked, 
allowing  for  a  comparison  to  metrics  to  show  improvement.  This  allows  one  to  see  the 
effectiveness  of  risk  handling  measures.  Risks  are  considered  improved  as  risk  levels 
decrease. 
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FIGURE  1.9-1:  RISK  LEVEL  -  LIKELIHOOD  VS.  CONSEQUENCE 

The  above  chart  depicts  the  five  levels  of  likelihood  and  risk,  and  shows  the  breakdown 
into  risk  level.  Green  indicates  low  risk,  yellow  medium  risk,  and  red  shows  high  risk. 
By  this  point  in  the  design,  there  should  be  no  high  risk  items,  as  risk  items  should  flow 
in  the  direction  of  the  arrow.  Monitoring  helps  in  tracking  this  flow. 


1.9.2  APPROACH 

By  improving  CASTOR’S  management  process,  risk  shall  be  reduced.  The  implemented 
system  includes  a  tracking  spreadsheet  and  a  process  of  listing  components  and  their 
technical  risks.  The  last  person  to  update  the  item  is  also  tracked  in  the  system. 

An  initial  project- wide  risk  assessment  was  completed  to  determine  where  components 
stand  and  what  areas  needed  additional  focus.  This  involved  contacting  leaders  of  each 
subsystem  and  discussing  risks  and  mitigation  strategies.  Next,  further  progress  was 
made  by  discussing  the  list  of  risks  with  team  leads  to  increase  the  robustness  of  the 
spreadsheet. 

Further  enhancement  of  the  risk  management  spreadsheet  is  an  ongoing  process.  Care 
must  be  taken  not  to  overload  the  system  by  delving  too  deeply  into  compounded 
problems,  and  to  focus  on  the  most  critical  risks.  While  initially  adding  risks  to  the 
database  was  encouraged,  feedback  from  CDR  showed  that  risks  should  be  limited  to 
twenty  or  thirty  important  risks,  rather  than  nearly  a  hundred  detailed  risks.  As  a 
response,  higher  level  risks  from  the  spreadsheet  were  categorized  and  combined  in  order 
to  develop  a  concise,  but  comprehensive  spreadsheet  of  risks.  Thus  the  database  was 
condensed  to  focus  on  the  true  concerns  for  the  project. 


1.9.3  ASSESSMENT  MODEL 

Various  characteristics  of  risk  are  tracked  to  gain  a  sense  of  risks.  These  include  the  area 
of  risk  (hardware,  software,  operational,  programmatic,  manufacture,  transport,  etc.),  the 
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risk  dependency  (what  else  must  fail  first),  likelihood,  consequence,  mitigation, 
diagnostic,  and  repair  or  backup  method.  Subsystems  are  asked  to  self-report  estimates 
of  their  risks  and  address  these  categories.  In  considering  risks,  personnel  should  be 
aware  that  critical  changes  that  affect  multiple  systems  can  have  far-reaching  effects. 
These  can  cause  other  subsystems  to  make  numerous  changes  to  their  system  and  thus 
increases  risk  level.  Since  the  level  of  risk  is  measured  by  the  likelihood  and 
consequence,  changes  such  as  this  increase  the  consequence  level  and  thus  are  reflected 
in  the  tracking  process. 

Relationships  between  risks  are  shown  as  ‘dependencies.’  Direct  links  between 
subsystems  can  lead  to  similar  probabilities. 

In  order  to  maintain  consistency  between  subsystems,  team  members  updating  the 
spreadsheet  are  asked  to  consider  the  scheme  in  Table  1.9-1: 


TABLE  1 .9-1 :  RISK  PROBABILITY  VS.  CONSEQUENCE 


Likelihood  or 
Consequence 
Level 

Likelihood 

Consequence 

1 

«  1% 

Inconvenience 

2 

-1% 

Causes  difficulties/delays,  but  can  be  corrected  or  handled 

3 

-10% 

Compromises  mission 

4 

-25% 

Mission  Failure  or  Partial  Mission  Failure 

5 

-50% 

Injures  people  or  harms  launch  vehicle  &  payloads; 

Total  Mission  Failure 

Further  work  should  involve  tracking  the  assurance  level  of  the  evaluator  (whether  this  is 
a  tested  likelihood  or  a  complete  guess). 


1.9.4  TECHNICAL  RISK 

Technical  risks  are  tracked  in  a  spreadsheet.  Each  risk  item  is  looked  at  individually  and 
considered  for  thoroughness.  Higher  risk  items  are  initially  flagged  so  as  to  prioritize 
them.  Currently  medium-risk  items  include  the  anode  (high  voltage  affecting  system), 
camera  lens  degradation,  and  reaction  wheel  failure.  The  next  set  of  high  risk  items 
includes  magnetometer  failure,  schedule  slips,  reaction  wheel  malfunctions,  torque  coil 
failures,  solar  panel  deployment  failure,  and  others.  Mitigations  range  from  using  the 
engine  to  de-saturate  to  modifying  the  duty  cycle  to  account  for  low  power  input. 
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A  meeting  with  the  Power  team  took  place  to  discover  the  relationship  between  power 
and  voltage  converter  failures  and  various  components.  A  single  converter  failure  could 
cause  an  entire  system,  for  instance  ADCS,  to  become  inoperable.  Since  most  ADCS 
components  work  on  5V  power,  only  the  torque  coils  will  operate  should  there  be  a 
failure.  Thus  analysis  of  the  discussion  also  led  to  the  discovery  of  unlisted  risks,  such  as 
inhibits,  and  the  difference  between  the  battery  charging  circuit  and  the  MPPT.  Careful 
checking  must  be  conducted  to  avoid  errors,  and  to  discover  relationships  between 
failures. 


1.9.5  COST  ESTIMATE 

Assessment  of  costs  is  more  straightforward,  in  that  spending  has  been  tracked  over  the 
last  year  and  a  spreadsheet  has  been  implemented  to  track  expenditures.  Details 
regarding  expenditures  can  be  found  in  2.1.4  of  the  fileshare.  Income,  or  available  funds, 
is  constrained,  and  shall  be  determined  based  on  a  detailed  cost  projection  plan.  The 
current  method  for  dealing  with  this  limitation  is  to  delay  the  purchase  of  expensive,  high 
TRL  components,  and  instead  test  with  engineering  mockups  until  funding  can  be 
secured.  It  has  been  noted  that  for  FCR  in  January,  according  to  UNP  representative 
Abbie  Stovall,  UNP  does  not  expect  a  flight-ready  satellite,  but  a  proto-flight  satellite. 
Instead,  high-cost  flight  hardware  can  be  purchased  later,  as  long  as  the  interfaces  and 
controllability  can  be  modeled.  For  instance,  purchase  of  one  reaction  wheel  and  a 
demonstration  of  functionality  will  suffice,  rather  than  purchasing  (and  integrating)  all 
three  reaction  wheels.  Functionality  of  the  other  two  reaction  wheel  should  be  verified 
by  integrating  engineering  models  into  the  system.  This  provides  the  advantage  of 
reduced  cost  as  well  as  sufficient  testing. 

Summary  of  Cost  Risks: 

Limited  Budget 

o  Consequence:  students  spend  excessive  amounts  of  time  re-creating  COTS 
components  to  reduce  costs;  adverse  effect  on  schedule  adherence 

o  Dependent  on  stringent  monetary  control  and  limited  donations 

o  Mitigation:  Ask  companies  for  material  donations  (such  as  solar  cells)  to 
reduce  costs  while  not  impacting  student  workload. 

Exceeding  budget 

o  Consequence:  Strain  on  resources;  could  lead  to  lack  of  funding  for  testing 
and  manufacture  of  satellite,  as  well  as  purchase  of  components 

o  Dependant  on  insufficient  tracking  and  spending  policies;  inability  to 
accurately  project  costs 
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o  Mitigation:  include  margining  in  cost  projections;  outline  of  all  large-cost 
items  &  cost  estimates;  delay  purchase  of  expensive  items  until  funding  is 
secured;  testing  with  less  costly  ‘engineering  units’  avoids  potential  of 
damaging  expensive  hardware  during  testing  and  thus  having  to  make 
replacement  purchases 

Lack  of  funding  for  testing  and  manufacture  of  satellite 

o  Consequence:  serious  delays  which  will  adversely  affect  progress  along 
UNP  schedule 

o  Dependencies:  insufficient  funds  (lack  of  donors);  going  over  budget 

o  Mitigation:  Promote  satellite  to  potential  donors;  careful  not  to  drastically 
exceed  budget; 

Other  methods  for  dealing  with  cost  risk  that  are  already  under  implementation  include 
cost  margining  and  purchasing  restrictions.  Costly  items  must  be  approved  by  faculty 
and  staff.  Garrett  Fritz  has  done  some  work  on  cost  projection  modeling  for  the  future  of 
the  program. 


1.9.6  SCHEDULE  RISK 

Schedule  risk  is  high  in  this  program,  thus  great  attention  has  been  given  to  compiling 
schedules  from  teams  and  integrating  them  with  a  systems  master  schedule.  Freeze  dates 
have  been  created  to  help  track  design  phases  and  keep  teams  at  the  same  stage  in  design. 
Essentially  the  chosen  method  for  reducing  schedule-slip  risk  involves  early 
identification  of  slips,  re-working  of  schedule  to  reflect  realistic  delays  (and  flow-down 
to  other  systems),  and  reallocation  of  labor  and  resources  to  meet  changing  demands. 
Margins  in  the  schedule  allow  for  improved  schedule-tracking,  along  with  advanced 
freeze  dates  and  compilation  deadlines.  Subteams  are  additionally  encouraged  to  adhere 
to  the  schedule  by  taking  part  in  schedule  creation  and  thus  being  held  responsible. 

1.10  DOCUMENTATION  SUMMARY  (A.  FUHRMANN) 


1.10.1  COMMAND  MEDIA 


Command  Media  refers  to  all  the  documentation  that  is  actively  managed  and  tracked  by 
the  systems  teams.  These  documents  are  divided  into  easily  accessible  frozen  sets  so  that 
modifications  can  be  viewed  over  time.  Generally  a  command  media  freeze  occurs  when 
documentation  is  due  to  UNP  or  for  an  internal  review.  Freezing  the  command  media 
gives  the  systems  team  an  opportunity  to  review  it  and  make  comments  before  final  edits. 
In  between  these  freezes  the  command  media  is  often  updated  to  reflect  the  most  up  to 
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date  changes.  Each  type  of  document  has  a  specific  approval  process  for  editing  and 
submitting  to  systems  during  this  inter-freeze  period. 


pkato  fl 

Phase  B 

Phase  C 

Phase  D 

Build  and  Test 

Phase  E 

Launch  and  Operations 

Preliminary 

Complete 

Development 

Design 

Design 

FIGURE  1.10-1:  COMMAND  MEDIA  PHASES 


The  command  media  are  tracked  through  phases  A-E  which  closely  corresponds  to  the 
NASA  system  used  to  track  documentation  throughout  a  program.  Below  are  all  of  the 
command  media  listed  with  the  project  phases  they  most  directly  correspond  to. 


Document/Model 

Phases 

Requirements  Verification  Matrix  (RVM) 

A-B 

Work  Breakdown  Structure  (WBS) 

A 

Program  Schedule 

A-C 

Budgets  (MEL,  Data,  Power,  Communications) 

A-C 

CONOPS 

A-C 

Risk  Mitigation  and  Safety 

A-C 

Integrated  Systems  Model 

A-E 

Interface  Control  Documents 

B-C 

CAD  Models 

B-C 

Systems  Diagram 

B-D 

Electrical  Schematic  Diagrams 

B-D 

Manufacturing,  Assembly,  and  Integration  Plan 

B-D 

Testing  Plans  and  Reports 

B-D 

Design  Document 

B-D 

On-Orbit  Handbook 

D-E 

TABLE  1.10-1:  CASTOR  COMMAND  MEDIA 


1.10.2  SUBVERSION  REPOSITORY 


All  of  the  CASTOR  Command  Media  is  stored  on  a  subversion  repository  which  is 
broken  down  as  follows: 

•  Management 

•  Systems 

•  Sub  teams 

•  Shared 

Each  of  these  sections  has  different  levels  of  access.  Subteam  folders,  for  example,  offer 
space  for  each  of  the  systems  to  work  on  their  command  media  before  submitting  it  to 
systems  for  approval.  The  systems  team  then  makes  the  determination  of  whether  or  not 
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that  document  is  ready  for  submission  to  UNP.  Those  final  documents  are  then  stored  in 
a  systems  level  folder. 

The  structure  of  the  repository  prevents  multiple  editors  from  overwriting  changes  if  they 
are  working  on  a  document  at  the  same  time.  If  there  is  a  conflicted  copy  then  the 
repository  will  advise  the  author  to  update  to  the  newest  version  before  submitting  their 
changes. 


1.10.3  ENGINEERING  CHANGE  ORDERS 


An  Engineering  Change  Order  (ECO)  is  the  documentation  process  followed  to 
implement  significant  changes  that  affect  multiple  subsystems.  Its  purpose  is  to  ensure 
continuity  of  design  and  to  resolve  potential  conflicts  which  may  arise  from  the  design 
changes.  The  ECO  creation  process  serves  as  a  mini-review  for  significant  changes  so 
that  all  the  sub  teams  are  on  the  same  page.  This  process  is  to: 

o  Deliver  the  proposed  ECO  to  all  directly  affected  subsystems  for  review 

o  Subsystems  change  specifics  and  inform  the  systems  team 

o  Deliver  the  current  proposed  ECO  to  all  other  teams  for  review 

o  Check  with  systems  team  again 

o  Perform  a  sign-off  of  the  ECO  at  a  team  leads  meeting 

This  process  managed  by  “ECO  Manager”  member  of  Systems  Team  who  is  responsible 
for  making  sure  that  all  relevant  parties  are  committed  to  the  new  design  change  before  it 
is  signed  off.  There  have  been  six  ECOs  throughout  the  CASTOR  program  and  there 
have  been  none  so  far  this  semester.  However,  the  process  is  still  in  place  in  case 
significant  changes  still  need  to  be  made. 
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• 

CASTOR 

ENGINEERING  CHANGE  ORDER 

ECO# 

002 

Originator  1  Date  Submitted 

ECO  Status 

Revision 

R.  McLinko  1 2009/1 1/03 

Submitted 

01 

Changing  Elements 

ADCS  System  Design 

Reason  For  Chanqe 

ystem  has  been  shown  to  be  inadequate  to  correct  for  disturbance  torques  throughout  the 
lite.  Furthermore,  it  is  much  heavier  and  more  complicated  than  other  options. 

The  current  nitrogen  gas  s 
operational  life  of  the  sate 

Description  of  Change 

hange  are  as  follows: 
of  the  satellite  is  removed 

added  to  the  satellite,  orthogonal  to  the  existing  one 
fed  to  the  satellite  in  mutually  orthogonal  directions 
to  "tumble"  during  eclipse 
n  is  removed 
ite  the  structure 

wheels  will  be  used  to  replace  the  engine  gimbal  system 

The  key  elements  of  the  c 
-The  nitrogen  gas  system 
-Two  reaction  wheels  are 
-Three  torque  coils  are  adc 
-The  spacecraft  is  allowed 
-The  engine  gimbal  systen 
-A  magnet  is  added  oppos 
-The  magnet  and  reaction 

ECO  Board  Members 

Signature 

Date 

Comments 

ECO  Manager 

Operations  Lead 

ADCS  Lead 

Avionics  Lead 

Communications  Lead 

Propulsion  Lead 

Power  Lead 

Thermal  Lead 

Structures  Lead 

ECO  Manager  Notes 

FIGURE  1.10-2:  ENGINEERING  CHANGE  ORDER 


1.11  OUTREACH  SUMMARY  (J.  JAMES) 


Reaching  out  to  the  community  is  an  important  goal  of  CASTOR.  In  order  to  encourage 
enthusiasm  for  the  sciences  and  exploration  of  the  frontier  beyond  Earth,  CASTOR  has 
been  involved  with  several  outreach  programs  this  semester.  These  include  Campus 
Preview  Weekend  (CPW)  and  Teach  for  Spark.  Past  outreach  events  include 
participation  in  the  Freshman  Orientation  Activities  Midway,  Teach  for  Splash,  and 
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participation  in  the  Students  for  the  Exploration  and  Development  of  Space  (SEDS) 
Project  Expo.  CASTOR  also  brings  a  variety  of  MIT  students  into  the  project  through 
the  Undergraduate  Research  Opportunities  Program. 


Teach  for  Spark! 

In  March,  2010,  CASTOR  participated  in  Spark  -  a  program  geared  toward  reaching  out 
to  middle  and  high  school  students.  During  several  sessions  on  the  weekend,  CASTOR 
members  engaged  students  by  holding  a  workshop  on  how  to  “Build  a  Satellite.” 
CASTOR  mentors  coached  the  young  scientists  on  how  to  build  satellites  out  of  various 
goodies  (such  as  graham  crackers,  pretzels,  marshmallows  and  toothpicks).  Satellites  had 
to  pass  thermal  testing  in  the  microwave  and  a  load  test  (i.e.  drop  test),  while  staying 
close  to  a  cost  estimate  and  target  mass.  The  class  was  a  big  success,  and  the  students  left 
excited  about  learning  about  space  (see  Figure  1.11-1). 


FIGURE  1.11-1:  SPARK  STUDENTS  WITH  CHOCOLATE  SATELLITE 


2  CDR  LEVEL  DESIGN 


2.1  OPERATIONS 


2.1.1  SUMMARY  OF  OPERATIONS  (J.  ROBINSON) 
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The  Concept  of  Operations  (CONOPS)  details  the  functions  and  timelines  of  the 
CASTOR  Satellite  and  supporting  ground  systems  during  all  phases  of  the  mission.  The 
CONOPS: 

•  Establishes  a  structure  for  CASTOR  mission  operations. 

•  Aids  spacecraft  design  by  detailing  the  events  that  occur  during  each  mission 
phase  and  during  failure  scenarios. 

•  Supports  the  development  of  ground  operations  and  support  systems. 


CASTOR  operations  are  divided  into  six  phases,  described  below: 

•  Pre-Launch  -  Flight  Model  (FM)  interaction  prior  to  launch 

•  Launch  -  Liftoff  until  lightband  separation  from  LV/ESPA  Interface 

•  On-Orbit  Deployment  -  Communications  acquisitions,  de-tumble,  deployment  of 
solar  arrays,  and  sun-pointing  attitude. 

•  Commissioning  -  Subsystem  health  verification  and  DCFT  start-up  and  initial 
operations 

•  Normal  Operations  -  On-orbit  maneuvers  and  DCFT  operating 

•  Decommissioning  -  De-orbit  and  re-entry  procedures 


These  phases  are  described  in  the  following  section.  The  CASTOR  CONOPS  document 
further  describes  the  CONOPS  details.  The  CONOPS  document  can  be  found  in  section 
3.2-Operations  in  the  fileshare. 


PRE-LAUNCH  PHASE 

Pre-launch  operations  can  be  divided  into  three  parts:  mission  integration,  ground  support 
and  transportation  and  final  checkout. 

Mission  Integration 

The  mission  integration  will  consist  of  the  final  assembly  of  CASTOR  prior  to  shipment. 
This  phase  will  be  led  by  the  structures  team.  This  will  consist  of  all  assembly  and  testing 
of  the  CASTOR  flight  model.  Throughout  this  phase,  detailed  documentation  must  take 
place  on  component  testing  and  observed  results.  This  documentation  will  be  saved  for 
reference  in  case  of  launch  support  or  on-orbit  questions. 

Ground  Support  and  Transportation 

Transportation  of  the  satellite  to  the  launch  site,  and  all  preparations  necessary,  will  be 
managed  by  the  systems  team.  The  Ground  Support  Equipment  (GSE)  will  be  made  up  of 
the  shipping  container,  mobile  ground  station  interface  (for  communications  testing), 
battery  charging  devices,  Xenon  filling  device,  lifting  harnesses,  and  any  tools  necessary 
(such  as  a  torque  wrench).  The  transportation  medium  for  the  satellite  is  TBD. 
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Final  Checkout 

The  operations  team  will  manage  the  final  checkout,  that  is,  the  final  maintenance  and 
tests  of  the  satellite  just  before  integration  with  the  launch  vehicle.  This  inspection  will 
ensure  that  no  damage  occurred  during  transport,  and  prepare  the  satellite  for  integration. 
Actions  that  will  occur  during  this  inspection  include  filling  the  Xenon  tank,  charging  the 
batteries,  and  final  performance  checks  of  the  avionics,  communications,  power, 
propulsion,  and  ADCS/GNC  subsystems.  This  checkout  will  take  place  in  the  facilities 
that  the  systems  team  has  arranged  for  this  purpose.  As  this  is  not  being  performed 
remotely,  no  communication  system  will  need  to  be  implemented.  Twelve  hours  are 
budgeted  for  these  checkouts,  in  order  to  provide  enough  time  to  fix  any  problems  that 
arise.  Following  successful  completion  of  these  checkouts,  the  satellite  will  be  turned 
over  to  the  launch  vehicle  integration  team;  the  operations  team  will  not  participate  in 
integration,  but  will  be  available  to  answer  questions  if  necessary.  Integration  is 
estimated  to  take  5-8  days  (TBR). 

Following  integration,  a  visual  check  will  take  place  (with  an  estimated  duration  of  6 
hours),  to  ensure  that  nothing  was  damaged  during  integration.  This  check  is  only  a 
visual  check,  and  will  not  require  any  communication  with  the  satellite  itself.  It  is  only  to 
ensure  that  the  satellite  has  sustained  no  physical  damage  during  integration. 

Considerable  margin  has  been  built  into  this  check,  to  provide  enough  time  to  identify 
any  damage  and  to  decide  on  the  best  course  of  action  to  take  (since  the  satellite  will 
already  be  attached  to  the  ESPA  ring  and  the  launch  vehicle).  After  this  visual  check  and 
any  necessary  repairs,  the  satellite  will  wait  for  the  launch  date.  Since  this  wait  may  be 
indefinite,  the  batteries  will  be  re-charged  approximately  every  11  (TBR)  days.  (Nickel 
cadmium  batteries  lose  their  charge  after  about  1 1  (TBR)  days,  even  if  they  are  not  in 
use;  if  the  launch  wait-time  is  longer  than  this,  they  will  need  to  be  recharged.)  If 
batteries  must  be  launched  with  minimal  charge  (as  understood  by  current  UNP 
guidelines),  the  batteries  will  be  drained  prior  to  launch.  If  batteries  are  allowed  to  be 
charged,  the  batteries  will  be  charged  one  final  time  a  few  hours  before  launch.  The  final 
determination  of  battery  charge  will  depend  on  the  understanding  with  the  launch  vehicle 
provider.  The  expected  scenario  (and  worse  case)  is  that  of  launching  with  fully  drained 
batteries. 

The  following  is  a  list  of  future  work  that  needs  to  be  completed  at  the  time  of  this 
documents  writing: 

•  Transportation  Procedures 

o  Ground  support  equipment 

•  Xenon  Tank  Filling  Procedures 

•  Battery  Charging  Procedures 

•  Final  FM  Integration  and  Handling  Procedures 

o  Inspection  and  Structural  Verification  (Torque  Check)  Procedures 
o  Satellite  Arming  Procedures 
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LAUNCH  PHASE 

Launch  operations  will  be  managed  by  the  launch  vehicle  provider  and  the  primary 
payload  team.  Members  of  the  team  will  be  present  for  launch,  in  case  of  problems  with 
the  satellite,  but  otherwise  will  perform  no  operations  until  the  satellite’s  release  from  the 
ESPA  ring. 


ON-ORBIT  DEPLOYMENT  PHASE 

The  requirement  of  the  deployment  phase  is  to  safely  deploy  the  solar  arrays  so  that  the 
CASTOR  mission  is  not  negatively  affected.  The  objective  of  the  deployment  sequence  is 
to  ensure  proper  analysis  of  the  satellite.  Health  is  first  checked  upon  contact  with  the 
satellite,  and  then  the  software  will  run  diagnostic  tests,  followed  by  extensive  testing  of 
the  ADCS  system.  The  ideal  state  prior  to  deploying  the  solar  arrays  is  a  fully  controlled 
satellite  with  sun -pointing  capabilities.  Under  these  circumstances,  the  satellite  will 
remain  in  the  same  operation  state  but  have  an  altered  physical  state. 

Deployment  to  First  Contact 

Upon  release  from  the  ESPA  ring,  the  on-orbit  deployment  phase  will  begin.  A  signal 
will  be  sent  from  the  ESPA  ring  to  TBD,  notifying  TBD  that  the  release  is  complete. 

Both  the  nature  and  the  destination  of  the  signal  are  unknown  at  this  time.  Upon 
separation,  the  satellite  will  turn  on  and  start  up  the  initial  housekeeping  task,  where  the 
satellite  is  in  an  idle  mode,  charging  batteries  and  waiting  for  a  signal  from  the  ground. 
Additionally,  in  this  task  will  power  up  the  modems  when  the  batteries  reach  22  V 
(TBR).  Basic  health  sensors  as  described  below  will  be  powered  at  this  time  as  well.  No 
data  will  be  collected  and  all  non-essential  components  will  be  turned  off  to  ensure  that 
the  satellite  can  survive  indefinitely  in  this  mode.  The  first  communications  with  the 
ground  will  be  initiated  by  operators  at  the  MITControlCenter  through  the  HETE  Ground 
Station. 

For  the  first  series  of  contacts,  operators  will  check  the  critical  health  data  and  telemetry 
data  to  ensure  that  the  satellite  is  functioning  properly.  Critical  health  data  includes  solar 
panel,  battery,  and  load  voltages  and  currents,  as  well  as  attitude  sensors  and  temperature 
sensors.  The  satellite  clock  will  be  updated  via  ground  commands  on  the  first  contact  The 
GPS  will  not  be  turned  on  initially.  The  satellite  will  send  real-time  data  at  a  requested 
data  rate  of  all  voltage,  current,  temperature,  and  attitude  sensors  on  the  bus  as  shown  in 
Table  2.1-1. 


TABLE  2.1-1.  INITIAL  REAL-TIME  HEALTH  TELEMETRY 


Subsystem 

TLM  Description 

EPS 

Battery  Voltage,  Battery  Current,  Solar  Array  Current  (x4),  Solar  Array 
Voltage  (x4),  PDU  Voltage  (x2),  PDU  Current  (x2) 
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Thermal 

Temperature  of  Battery  (x?),  PDU  (x?),  Avionics  Box  (x?),  Solar  Array 
(x4),  others? 

ADCS 

Magnetometer  Voltage  (x3),  Gyro  rates  (x3),  Accelerometer  (x3),  Sun 
Sensor?  (x?) 

Comm 

n/a 

GNC 

n/a 

Others 

TBD 

TABLE  2.1-2:  TLM  DESCRIPTION 


The  largest  uncertainty  in  this  phase  is  the  consistency  of  the  communications  signal.  If 
the  ground  passes  are  frequently  interrupted,  the  command  to  deploy  the  solar  arrays 
might  come  prior  to  the  desired  pointing  of  the  satellite.  The  analysis  of  this  possibility 
and  the  probability  of  communications  problems  are  ongoing,  and  will  affect  the  final 
operation  plans. 

Software  Checkout 

After  checking  critical  health  data  and  setting  the  clock,  operators  will  perform  checks  on 
the  more  complex  software  pre-loaded  to  ensure  that  no  software  was  corrupted  during 
launch  and  start-up.  If  any  software  fixes  are  needed  or  any  software  needs  to  be  loaded, 
it  will  be  done  at  this  time.  The  software  will  be  checked  and  uploaded  in  order  of 
necessity.  That  is,  the  higher-level  tasks  such  as  the  scheduler  or  DCFT  operations  task 
will  not  be  loaded  until  needed.  The  first  software  tasks  to  be  loaded  are  the  file 
management  system  and  the  satellite’s  executable  task. 

The  executable  task  and  file  management  system  will  allow  operators  to  collect  data 
between  ground  station  contacts  (store  and  forward  technique).  This  is  especially 
important,  as  the  communications  with  the  satellite  will  be  intermittent  until  stabilization 
and  deployment  of  solar  arrays.  A  test  of  comparing  collected  data  and  real-time  data  will 
ensure  that  the  file  system  is  properly  writing  data  and  the  timing  in  the  software  is 
correct.  Critical  health  will  be  collected  continuously  at  15  sec  sampling  (TBR)  from  this 
point  forward  if  there  is  sufficient  coverage  time  to  transmit  it. 

ADCS/GNC  Checkout 

Next,  operators  will  checkout  the  ADCS  and  GNC  instruments  necessary  to  de-tumble. 
This  is  currently  assumed  to  be  done  manually  by  operators  and  engineers  looking  at 
ground  telemetry,  however,  the  test  may  be  written  into  the  software. 

ADCS  and  GNC  De-tumble  Checkout  and  De-tumble: 

•  GPS  cold-start  (update  computer  time  if  within  proper  threshold) 

•  Check  that  gyroscopes  are  operational,  then  calibrate 
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•  Turn  on  magnetometers  and  recalibrate  if  necessary 

•  Checkout  torque  coils 

•  Checkout  reaction  wheels 

•  Fire  torque  coils  or  reaction  wheels  (TBR  as  to  which  exactly),  using  the  readings 
from  gyroscopes  and  magnetometers  to  de-tumble 

Upon  de-tumbling  the  ADCS  software  will  be  tested  to  see  if  the  satellite  can  point  its 
+Z-axis  towards  the  sun  and  track  the  sun.  This  will  ensure  that  post-deployment,  the 
ADCS  system  can  track  the  sun.  Following  this  test  and  when  the  attitude  rates  are  within 
limits  (TBR),  ground  operators  will  command  the  panels  to  deploy.  During  deployment 
and  for  10  min  (TBR)  after  deployment,  no  attitude  actuators  will  be  active  to  ensure  that 
there  is  no  interference  with  deployment  dynamics.  After  the  10-minute  timeout,  the 
satellite  will  point  in  a  sun-tracking  mode  (TBR,  depends  on  comm.).  The  command  will 
be  sent  on  the  first  of  subsequent  orbital  passes,  so  that  the  command  can  be  verified  on 
the  next  pass. 

Following  solar  panel  deployment,  the  ADCS  system  will  point  the  +Z-axis  towards  the 
sun  so  that  the  solar  panels  are  generating  the  maximum  power. 

ADCS  GNC  Solar  Panel  Pointing  Checkout  and  Pointing: 

•  Check  readings  from  gyroscopes,  magnetometers,  and  sun  sensor  to  know  where 
to  point  the  solar  panels 

•  Turn  on  reaction  wheels 

•  Monitor  sun  sensor  and  MPPT  output  to  confirm  pointing 

•  Use  reaction  wheels  rotate  body  until  solar  panels  are  pointed  at  the  sun 

•  Check  battery  charging 

The  satellite  will  communicate  with  the  ground  again  after  the  pointing  of  the  solar 
panels.  When  the  satellite  tracks  the  sun  and  the  batteries  are  fully  charged,  the 
spacecraft  will  enter  the  commissioning  phase. 

COMMISSIONING  PHASE 

The  objective  of  the  commissioning  phase  is  to  fully  qualify  the  satellite  prior  to  normal 
operations.  To  move  to  normal  operations,  two  major  tasks  must  occur:  verification  of 
bus  health  and  DCFT  qualification  and  calibration.  The  phase  begins  with  fully  charged 
batteries,  a  de-tumbled,  sun-tracking  spacecraft,  and  deployed  solar  panels.  Then  the 
detailed  subsystem  checkout  process  begins. 

ADCS  Subsystem 

The  ADCS  system  checks  should  be  mostly  complete  by  this  point.  However,  additional 
tests  may  take  place  to  completely  verify  that  all  components  match  their  expected 
modeled  behaviors,  whereas  in  the  deployment  phase,  the  emphasis  was  on  overall 
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vehicle  health  and  general  attitude  pointing.  The  verification  steps  for  the  ADCS  system 
are  TBD  and  will  be  determined  by  the  ADCS  team. 

GNC  Subsystem 

The  CASTOR  GNC  system  will  be  verified  by  ensuring  that  the  hardware  and  software 
systems  interact  together  in  the  predicted  manner.  This  will  be  done  in  the  following 
steps: 

•  GPS  comparison  to  Two  Line  Element  sets  (TLEs) 

•  GPS  satellite  time  update 

o  GPS  comparison  to  Two  Line  Element  sets  (TLEs) 

•  Orbital  propagator  verification 

o  Downlink  predicted  state  and  compare  to  ground  station  propagator 

■  Propagator  validation  for  requirements  by  comparing  to  error  to 
GPS 

o  GPS  updates  propagator  epoch  every  24  hours  (TLE) 

•  Check  desired  pointing  for  maneuver  at  different  orbital  positions 

•  Verify  software  interaction  with  operations  task 

Power  Subsystem 

The  power  subsystem  check  will  determine  if  each  of  the  solar  panels  is  providing  the 
expected  amount  of  power  at  the  expected  efficiency,  and  if  each  of  the  power  lines  are 
working.  Like  the  ADCS/GNC  check,  much  of  this  has  happened  previously,  however 
emphasis  will  be  towards  matching  the  data  with  the  expected  behavior  and  model  of  the 
satellite. 

Thermal  Subsystem 

The  temperature  sensors  will  be  providing  readings  throughout  commissioning.  The 
primary  thermal  subsystem  verification  will  occur  by  ensuring  that  no  components  reach 
temperatures  hotter  or  colder  than  their  operational  constraints,  with  and  without  DCFT 
operations.  Additionally,  the  thermal  subsystem  can  be  fully  verified  by  comparing  the 
temperature  sensors  to  the  predicted  models.  This  will  allow  either  the  model  to  be 
updated  or  sensors  to  be  identified  as  faulty. 

Propulsion  Subsystem 

The  propulsion  system  has  two  major  tasks  during  commissioning:  DCFT  power-up  and 
initial  operations.  The  propulsion  system  needs  the  camera  system  (avionics),  the  power 
system,  and  the  attitude  system  to  be  functional  prior  to  execution.  Additionally,  software 
safety  checks  must  be  in  place  to  limit  the  power  system  and  the  timing  of  the  DCFT 
thrusting  operations. 

DCFT  Power-Up 
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Initial  start-up  of  the  DCFT  requires  the  following  steps: 

1.  Bake  out  (~3  hours) 

2.  Condition  cathode: 

a.  Supply  2A  at  3.3  V  for  90  min:  6.6  W  (TBR) 

b.  4A  at  7.9  V  for  90  minutes:  31.6  W  (TBR) 

c.  6  A  at  12.8  V  for  60  minutes:  76.8  W  (TBR) 

3.  Then  0.36 A  at  200V  of  actual  thrusting  for  15  minutes:  72  W  (TBR) 

a.  Thrust  in  velocity  direction 

4.  Take  images  of  plume  every  1-2  minutes  (TBR) 

5.  Turn  off  anode  flow  and  turn  on  cathode  heater/keeper  (TBR) 


The  batteries’  capacity  has  been  selected  to  ensure  that  this  start-up  will  not  be 
interrupted  by  eclipse.  However,  the  high  power  activities  will  be  scheduled  to  occur 
during  the  sunlit  portion  of  the  orbit  to  minimize  the  discharge  on  the  batteries. 


DCFT  Initial  Operations 

The  goal  of  the  initial  operations  is  to  calibrate  the  DCFT  while  also  meeting  the 
minimum  success  criteria  of  the  mission.  These  minimum  success  criteria  are  to  operate 
the  DCFT  and  demonstrate  a  change  in  the  orbit  with  the  DCFT.  The  source  of 
commands  for  operating  the  DCFT  (ground-based,  scheduled,  or  autonomous)  is  TBR. 
The  orbital  change  will  be  a  semimajor  axis  increase.  This  will  be  accomplished  by 
operating  the  DCFT  while  within  15  degrees  (TBR)  of  the  thrust  axis.  The  verification  of 
the  maneuver  will  be  GPS  (primary)  as  well  as  TLE  (secondary).  A  significant  maneuver 
is  defined  as  a  100-meter  increase  in  the  semi-major  axis,  which  should  occur  after  ~15 
min  of  thrusting.  The  first  operations  of  the  DCFT  should  be  able  to  accomplish  this  task, 
however  if  the  pointing  is  off  or  the  first  firing  does  not  go  as  planned,  the  orbit  change 
may  not  be  complete. 

Upon  meeting  the  minimum  mission  criteria,  the  emphasis  will  be  placed  on  calibration 
of  the  DCFT.  The  procedures  for  the  calibration  are  TBD  from  the  propulsion  team.  In 
general,  it  will  involve  testing  different  flow  rates  to  see  the  power  draw  from  the  DCFT. 
A  final  flow  rate  will  be  selected  for  normal  operations.  Additionally,  the  camera’s 
imaging  capability  of  the  plume  will  also  be  determined,  and  the  final  camera 
configuration  (bits  per  pixel  and  image  resolution)  will  be  determined  prior  to  normal 
operations. 

Commissioning  Phase  Exit  Criteria 

The  commissioning  phase  will  end  and  the  normal  operations  phase  will  begin  when  the 
minimum  success  criteria  have  been  met  and  all  subsystems  are  functioning  properly  to 
allow  for  autonomous  operations.  As  stated,  the  minimum  success  criteria  are  to 
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successfully  operate  the  DCFT  and  thereby  demonstrate  a  change  in  orbit  with  the  DCFT. 
The  successful  operation  proof  will  be  completed  using  the  on-board  camera  and  power 
telemetry  data.  The  orbital  change  will  be  measured  by  the  onboard  GPS  or  ground-based 
sensors. 

Additional  steps  that  may  need  to  be  completed  prior  to  normal  operations  are  autonomy 
tests  with  software.  These  would  include  ensuring  that  the  autonomous  scheduling  and 
DCFT  operation  commands  are  executed  as  intended.  Tests  will  include  setting  the 
maximum  allowable  time  between  contacts  to  fire  the  DCFT  very  low  to  demonstrate  that 
the  software  will  automatically  shutoff  if  this  time  elapses. 

The  complete  details  of  these  software  tests,  their  implementation  on  the  flatsat  (or 
qualifications  model),  and  the  implementation  on  the  flight  model  will  be  outlined  in  the 
CONOPS  and  the  operational  procedures.  Normal  operations  will  begin  when  the  satellite 
is  merely  being  observed  for  the  entirety  of  its  mission  and  it  operates  in  a  predetermined 
manner. 


NORMAL  OPERATIONS  PHASE 

The  purpose  of  the  normal  operations  phase  is  to  fulfill  the  mission  objectives  of 
CASTOR.  The  basic  operations  in  this  phase  will  be  to  fire  the  DCFT  whenever  safely 
possible  (being  constrained  by  power,  lifetime,  Xenon,  and  thermal  survivability 
considerations),  and  to  return  payload  and  health  data  to  the  ground  station  for  analysis. 

A  basic  orbit  will  go  as  follows: 

•  Recharge  batteries  at  the  start  of  the  sun  period  by  pointing  solar  panels  to  sun 

•  When  batteries  are  sufficiently  charged  and  desired  thrust  and  power  producing 
angles  line  up,  operate  the  DCFT  (assuming  other  factors  are  within  limits) 

•  Take  picture  of  DCFT  every  firing  cycle 

•  Turn  off  the  DCFT  when  power  available  decreases  below  threshold  or  any  other 
factors  are  out  of  limit 

•  Orient  solar  panels  towards  the  sun  and  further  charge  batteries 

•  Coast  uncontrolled  in  eclipse  to  save  power  (TBR,  potential  predictive  maneuver) 

•  Send  pictures,  DCFT  data,  and  health  data  to  ground  station  when  overhead 

Safety  constraints  will  be  programmed  into  the  software  to  ensure  that  the  DCFT  does  not 
fire  after  three  days  (TBR)  without  contact  from  the  ground  station  to  ensure  that  the 
satellite  does  not  maneuver  away  from  its  predicted  location.  Additionally,  thermal, 
power,  ADCS,  and  GNC  tasks  will  monitor  the  health  of  the  satellite  and  alert  the 
operations  task  if  any  component  problems  occur  or  observed  parameters  are  out  of  the 
operational  range,  resulting  in  a  recommendation  to  enter  a  safe  operations  mode.  These 
modes  have  not  entirely  been  determined;  however,  they  will  be  described  prior  to  CDR 
and  tested  on  the  flatsat  and  other  software  modeling  tools  such  as  SpecTRM. 
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The  basic  orbital  changes  that  are  currently  planned  in  the  normal  operations  phase  of  the 
mission  are  simple  semimajor  axis  (radius)  increases  and  decreases.  This  will  be 
accomplished  by  thrusting  directly  with  or  against  the  velocity  vector.  Alternative  options 
are  plane  changes  (either  inclination  or  ascending  node  changes);  however,  these  are  not 
as  useful  for  the  engine  characterization  and  require  more  complicated  pointing,  so  they 
are  currently  not  in  the  design.  An  additional  orbit  that  may  be  tested  near  the  end  of  the 
mission  is  a  low  perigee  drag-reduction  orbit,  in  which  the  satellite  will  bum  specifically 
near  perigee  or  apogee  to  keep  the  energy  of  the  orbit  high  enough  to  prevent  re-entry,  as 
the  final  operations  mode  is  decommissioning  via  atmospheric  re-entry. 

The  satellite  will  operate  within  a  band  of  altitudes  from  400  km  (perigee)  and  700  km 
(apogee).  These  altitudes  were  selected  to  ensure  that  drag  effects  are  minimal  and  to 
ensure  that  the  satellite  does  not  progress  too  far  into  the  radiation  environment.  These 
numbers  are  TBR  and  will  likely  change  on-orbit  due  to  operational  optimization  of 
groundstation  coverage  and  the  thrusting  environment. 

The  normal  operations  phase  will  end  when  any  of  the  following  conditions  are  met: 

•  The  fuel  mass  is  approaching  the  de-orbit  limit  of  1kg  (TBR) 

•  The  orbit  is  lower  than  the  DCFT  can  compensate  for  drag  and  will  re-enter  soon 

•  Critical  components  have  failed  or  degraded  enough  to  warrant  decommissioning 
the  satellite 


DECOMMISSIONING  PHASE 

The  decommissioning  phase  of  the  mission  encompasses  the  end  of  life  of  the  spacecraft. 
A  NASA  (UARS)  decommission  plan  specifies  the  following  five  operations  during  this 
phase  in  order  to  minimizing  risk  to  other  spacecraft: 

•  Limit  the  on-orbit  lifetime  of  the  spacecraft  by  lowering  the  orbit  by  firing 
thruster  with  remaining  fuel. 

•  Minimize  the  potential  for  generating  orbital  debris  due  to  explosion  or 
collision  via  venting  remaining  on-board  fuel. 

•  Remove  the  ability  of  the  spacecraft  to  act  as  an  RF  source  by  disabling,  to  the 
extent  possible,  the  modem. 

•  Cease  active  attitude  control  of  the  spacecraft  by  disabling  actuator  control 
functions 

•  Leave  the  spacecraft  in  an  inert/powerless  state  by  disabling/severing  solar 
power  distribution  functions. 

Decommission  Plan  for  Upper  Atmospheric  Research  Satellite  (UARS),  2002.  Section 

2.0 

The  NASA  Handbook  on  Orbital  Debris  Mitigation  specifies  three  acceptable  options  for 
decommissioning  in  LEO: 
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•  Atmospheric  Entry 

•  Maneuvering  to  a  storage  orbit  (an  orbit  >2000  km) 

•  Direct  retrieval 


NASA  requires  that  the  probability  of  success  for  the  chosen  mission  decommissioning 
option  be  greater  than  90%. 

The  first  option,  atmospheric  entry,  is  a  common  decommissioning  technique,  which  has 
been  selected  for  this  mission.  The  second  option  is  not  feasible  because  it  is  unlikely 
that  it  would  succeed.  As  there  are  no  feasible  means  of  directly  retrieving  the 
spacecraft,  the  third  option  is  eliminated. 

However,  with  an  electric  propulsion  system  the  ability  to  make  a  controlled  entry  into 
the  atmosphere  is  limited.  This  is  because  in  lower  orbits  the  force  of  atmospheric  drag 
becomes  much  greater  than  the  engine  thrust.  Controlling  the  thrust  vector  and  attitude 
becomes  increasingly  energy-expensive  as  the  orbit  decreases  until  the  spacecraft  can  no 
longer  overcome  the  drag  forces  and  the  re-entry  becomes  uncontrolled. 

This  means  that  atmospheric  re-entry  must  be  uncontrolled.  NASA  specifies  that 
uncontrolled  re-entry  is  acceptable  if  it  can  be  proven  that  the  probability  of  human  injury 
is  less  than  0.0001. 


Event  Number  Duration 


Description 


FI 

0-52  days 

Lower  orbit  using  remaining  fuel 

F2 

as  needed 

Dispose  of  remaining  fuel  (thrusting 
or  venting) 

F3 

<  1  minute 

Disable  solar  arrays  (sever 
connection  to  PPT) 

F4 

1  minute 

Disable  ACS/GNC  to  cease  active 

control 

F5 

<  1  minute 

Shut  down  communications 

(modems) 

F6 

1  minute 

Shut  down  computer 

TABLE  2.1-3:  DECOMMISSIONING  TIMELINE 


The  CONOPS  also  describes  safe  modes,  failure  cases,  and  the  data  processing  plan. 
Please  reference  section  3.2  in  the  fileshare  for  those  details. 


2.1.2  GROUND  STATION  INTERFACE  (N.  ESSILFIE-CONDUAH) 


The  CASTOR  satellite  needs  to  be  controlled  through  established  reliable  communication 
connections.  This  ensures  the  ability  to  attain  data  or  control  it  whenever  necessary.  The 
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MIT  ground  station  thus  plays  a  role  in  meeting  this  requirement.  To  accomplish  this  goal 
of  sending  commands  and  requesting  data  from  the  satellite  the  MIT  Ground  Station  will 
be  established.  Essentially,  it  will  be  a  control  center  at  MIT,  which  will  make  use  of  the 
MIT  Ground  Station  GUI  to  send  commands.  A  trained  controller  will  operate  this.  The 
operator  will  send  commands/files  to  the  HETE  ground  station  in  Cayenne,  which  will  be 
in  contact  with  the  satellite  during  transmission  periods.  The  transmission  cycle  would 
start  after  the  commissioning  phase.  An  example  of  the  transmission  cycle  can  be  seen 
when  a  command  is  sent  requesting  sensor  data.  This  command  would  be  selected  and 
packetized  in  the  GUI  application,  which  would  send  the  packet  to  the  HETE  ground 
station  over  a  TCP/IP  connection.  The  HETE  ground  station  would  then  transmit  this 
command  to  the  satellite.  The  satellite  after  successful  or  unsuccessful  completion  of  the 
command  would  report  to  the  HETE  ground  station.  This  response  would  then  be 
forwarded  to  the  MIT  ground  station  control  center  over  the  TCP/IP  connection  for 
analyses. 


The  control  center  would  contain  two  to  three  computer  terminals.  Due  to  reliability, 
widespread  use,  and  price,  these  computer  terminals  will  be  the  standard  Athena 
machines.  While  these  will  have  the  same  hardware  as  Athena  machines,  they  will  not  be 
running  Athena  software  and  we  hope  them  to  be  dedicated  computers.  Based  on  the 
different  requirements  for  each  computer,  the  simulation  computer  will  be  running 
Windows  and  the  command  and  data  processing  computers  will  be  running  Linux.  Each 
computer  in  the  control  center  will  need  internet  access  to  connect  to  the  HETE  Cayenne 
ground  station  and  each  other.  Uninterruptable  power  will  be  necessary  to  ensure  that  if 
the  satellite  sends  down  data,  there  is  a  computer  ready  to  receive  it,  this  is  particularly 
important  during  the  on-orbit  deployment  and  commissioning  phases  when  progress  is 
mediated  by  commands  from  the  ground. 


I _ 

Command  and  Control  Center 


FIGURE  2.1-1:  GROUND  SYSTEM  LAYOUT 
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The  above  diagram  shows  the  modularization  of  the  task,  but  the  command  and  data 
processing  computers  are  intended  to  be  one  machine. 

In  addition,  the  command  and  data  processing  computers  will  also  be  designed  to 
interface  with  the  simulation  computer  for  ease  in  data  transfer. 


The  MIT  Ground  Station  through  the  command  computer  will  run  a  GUI,  written  in  java, 
providing  a  readily  understandable  interface  for  commands  to  be  sent  to  the  satellite  and 
for  received  data  to  be  viewed.  This  is  the  Ground  Station  Interface. 

The  look  and  feel  of  the  GUI  can  be  seen  in  Figure  2  below. 


»oo 

Ground  Station 

Sent  Data 

Received  Data 

PropulsionEngine  command: 

on  high  2009-11-08  00:00:00  200secs  high  0  0 


2009-11-03  16:44:57  :  Connection  Established.  Yay!!!  Please  send  command. 
2009-11-03  16:44:57  :  PropulsionEngine  command: 

2009-11-03  16:44:57  :  on  high  2009-11-08  00:00:00  200secs  high  0  0 


Ack  Command  Exit 


Send  a  command  to  the  satellite 
1  Propulsion  t  1 

r 


Engine 


high 


ON/OFF 

PRIORITY 


2009- 11-08  00:00:00  START  TIME 
1 200secs  DURATION 


high 


FIGURE  2.1-2:  GROUND  STATION  GUI 


To  meet  the  requirements  of  the  satellite,  commands  were  established  based  upon  the 
needs  of  each  subteam.  This  structure  was  then  used  to  govern  the  navigation  of  the 
commands  though  the  GUI 

Commands  sent  to  the  satellite  will  be  chosen  in  a  graphical  interface.  The  operator  will 
select  from  the  command  lists  below  the  commands  that  he  or  she  wishes  to  send.  One 
special  command  for  example  will  be  the  decommissioning  command.  Any  of  these 
commands  will  be  sent  to  the  HETE  ground  station  and  then  processed  by  the  satellite 
once  received  on-orbit. 
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Each  individual  subteam  determined  the  structure  of  their  commands  as  follows. 


TABLE  2.1-4:  ACS/GNC  COMMAND  LIST 


ACS/GNC 

ON/OFF 

PRIORITY 

START 

TIME 

DURATION 

TORQUE 

AXIS 

ID 

SIZE 

1  bit 

2  bits 

3  bytes 

3  bytes 

8  bytes 

24  bytes 

1  byte 

Total  (bits) 

GPS 

X 

X 

X 

X 

51 

MAGNETOMETER 

X 

X 

X 

X 

51 

GYROS 

X 

X 

X 

X 

51 

THRUSTER 

X 

X 

X 

X 

X 

306 

THRUSTER 

X 

X 

X 

X 

X 

59 

DETUMBLE 

MODE 

X 

X 

X 

27 

DETUMBLE  + 

POINT  MODE 

X 

X 

X 

27 

SUN  SENSOR 

X 

X 

X 

X 

51 

RXN  WHEEL 

X 

X 

X 

X 

X 

115 

CALIBRATE 

GYROS 

X 

X 

X 

27 

CHECKOUT  A 
MODE 

X 

X 

X 

27 

CHECKOUT  B 
MODE 

X 

X 

X 

27 

COMMISSION 

X 

X 

3 

TABLE  2.1-5:  STRUCTURES/THERMAL  COMMAND  LIST 


STRUCTURES/THERMAL 

PRIORITY 

TIME 

START 

SIZE 

2  bits 

3  bytes 

Total  (bits) 

DEPLOY  SOLAR  PANELS 

X 

X 

26 
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TABLE  2.1-6:  PROPULSION  COMMAND  LIST 


PROPULSION 

ON/OFF  (1 
bit) 

PRIORITY 
(2  bits) 

TIME 
START  (24 
bits) 

DURATION 
(24  bits) 

THRUST 
(8  bytes) 

SIZE 

1  bit 

2  bits 

3  bytes 

3  bytes 

8  bytes 

Total  (bits) 

CHECKOUT 

X 

X 

X 

27 

ENGINE 

X 

X 

X 

X 

X 

115 

VENT  FUEL 

X 

X 

X 

X 

51 

TABLE  2.1-7:  AVIONICS  COMMAND  LIST 


AVIONICS 

ON/OFF 

PRIORITY 

TIME 

START 

NORMAL 

(Y/N) 

COLLECTION 

RATE 

DESIRED 
DATA  LIST 

SIZE 

1  bit 

2  bits 

3  bytes 

1  bit 

4  bytes 

1  byte 

Total  (bits) 

SOFTWARE 

UPDATE 

X 

X 

26 

REBOOT 

X 

X 

26 

RELOAD 

MEMORY 

X 

X 

26 

COMPUTER 

X 

X 

X 

27 

DATA 

COLLECTION 

X 

X 

X 

41 

TABLE  2.1-8:  COMMUNICATIONS  COMMAND  LIST 


COMMUNICATIONS 

PRIORITY 

TIME 

START 

SIZE 

2  bits 

3  bytes 

Total  (bits) 

SEND  HOUSEKEEPING 
PACKET 

X 

X 

26 

SEND  EMERGENCY 
DATA  PACKET 

X 

X 

26 
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TABLE  2.1-9:  OPERATIONS  COMMAND  LIST 


OPERATIONS 

PRIORITY 

TIME 

START 

MANEUVER 

SELECTION 

SIZE 

2  bits 

3  bytes 

1  byte 

Total  (bits) 

BEGIN  COMMISSIONING 

X 

X 

26 

BEGIN  NORMAL 
OPERATIONS 

X 

X 

26 

BEGIN 

DECOMMISSIONING 

X 

X 

26 

GO-AHEAD 

X 

X 

26 

INITIATE  NEW 
MANEUVER 

X 

X 

X 

34 

The  command  lists  above  (compiled  with  help  from  Emily  Grosse  and  Ginny  Quaney) 
have  the  component  or  command  which  will  be  sent  on  the  left  column  and  the  content  of 
that  command  on  the  top  row.  For  example,  a  command  to  the  ACS  Reaction  Wheel  will 
contain  the  following  data:  On/Off,  Priority,  Start  Time,  Duration,  and  Torque 
information.  Some  of  these  commands  will  be  used  in  the  course  of  nominal  satellite 
operations  and  some  will  be  used  only  if  a  problem  is  observed.  For  example,  the 
operations  commands  and  the  ACS/GNC  checkout  mode  commands  will  be  used  even  if 
there  are  no  problems  on  the  spacecraft,  but  the  Avionics  software  update  or  reboot 
commands  should  not  have  to  be  used  unless  a  problem  is  detected. 

The  command  lists  will  see  a  revision.  The  result  of  the  revision  may  result  in  the 
restructuring  of  the  command  list  and  thus  the  GUI.  However,  it  will  go  to  satisfy 
requirements  of  data,  scheduling,  frequency  of  use  and  complexity  of  commands 
pertaining  to  the  satellite  as  specified  by  each  subsystem. 


To  help  this,  a  Command  Document  will  be  produced  to  thoroughly  document  the  needed 
structure  of  commands  to  operate  CASTOR  as  needed. 


2.1.3  SOFTWARE  PFAN  (J.  ROBINSON) 

The  following  software  plan  contains  segments  from  the  Software  Operations  Document, 
which  is  named  CASTOR_SW.doc  and  can  be  found  in  section  3.2  of  the  fileshare. 

Figure  2.1-3  shows  the  software  architecture  from  the  83x  design,  which  was  also 
presented  at  the  PDR.  The  avionics  section  has  a  slightly  different  diagram,  and  the 
complete  software  architecture  still  needs  to  be  finalized. 
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Operations 
Task 


FIGURE  2.1-3:  SOFTWARE  ARCHITECTURE  AT  PDR 


The  tasks  on  the  top  left  (operations,  navigation,  propulsion,  thermal,  attitude,  power,  and 
communications)  will  work  together  in  managing  CASTOR  as  well  as  ensuring  needed 
data  is  transmitted.  The  following  are  the  requirements  for  these  software  tasks.  Further 
work  will  be  done  to  analyze  the  structure  of  each  task  and  the  functions  that  will  take 
place  in  each. 


2. 1.3.1  OPERATIONS  TASK 
The  operations  software  task  has  the  following  requirements: 

OT-1  The  CASTOR  operations  software  shall  control  the  transition  of  CASTOR 
operation  modes  between  power  generating,  DCFT  operating,  eclipse,  and 
communicating  functions. 

OT-2  The  operations  software  shall  be  reprogrammable  and  allow  for  software  upgrades 
and  fixes  without  any  effect  on  the  core  CASTOR  systems  health. 

OT-3  The  operations  software  shall  collect  and  monitor  subsystem  hardware  and 
processes  to  include  creating  telemetry  files,  command  files,  and  safely  responding  to  any 
off-nominal  hardware  case. 

OT-4  The  operations  software  shall  track  DCFT  system  performance,  to  include 
tracking  firing  time,  Xenon  fuel  consumption,  operating  state,  and  power  parameters. 
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These  task  requirements  may  be  over  specified  for  the  operations  task.  Requirement  OT- 
3  will  most  likely  be  managed  by  a  separate  data  collection  and  storage  task,  and 
requirement  OT-4  may  be  split  into  the  propulsion  and  power  tasks. 

The  current  design  for  the  operations  task  is  to  have  a  two-part  system:  the  operations 
survival  software  (OP-S)  and  the  operations  execution  software  (OP-X).  This  is  similar  to 
the  FalconSAT-3  approach,  and  allows  for  the  basic  functionality  and  critical  health  to  be 
taken  care  of  in  a  stand-alone  task  (OP-S),  which  does  not  require  the  functionality  of  any 
high  level  subsystem  tasks  (such  as  pointing  or  DCFT  operations).  At  separation  or  after 
any  major  system  resets,  the  OP-S  software  will  initiate  the  first  communications  and 
verify  the  state  of  the  critical  components.  The  CONOPS  will  describe  the  software 
upload  steps  as  they  are  finalized.. 

An  additional  requirement  may  exist  in  the  operations  task  that  the  engine  cannot  fire 
after  a  specified  period  without  hearing  from  the  ground  station.  This  is  a  safety 
mechanism  that  still  needs  to  be  determined. 

2. 1.3. 2  NAVIGATION  TASK 
The  navigation  software  task  requirements  are  as  follows: 

NT-1  The  navigation  software  shall  provide  the  position  and  velocity  vectors  of  the 
satellite,  the  sun  position  vector,  and  the  ground  station  position  vector. 

NT-2  The  navigation  task  shall  determine  the  desired  pointing  orientation  for  each 
maneuver,  when  queried  by  the  operations  task. 

NT-3  The  navigation  software  shall  compare  GPS  data,  ground  tracking  information 
(TLEs)  and  an  on-board  orbital  propagator  prior  to  sending  any  commands  to  CASTOR, 
and  must  update  the  epoch  conditions  for  the  propagator  so  that  the  propagator  alone  can 
predict  communications  intervals  for  one  week  without  DCFT  operations. 


The  navigation  software  needs  to  provide  the  orbital  state  data  for  attitude, 
communications,  and  propulsion  purposes.  The  NT-2  requirement  alludes  to  the 
possibility  that  different  maneuvers  can  be  programmed  for  CASTOR.  Currently,  only  a 
semimajor  axis  change  (orbital  radius  or  altitude)  is  planned,  however  this  software  task 
would  allow  for  upgrades  if  additional  maneuvers  are  planned.  Whether  the  scheduling 
will  occur  on-board  CASTOR  verses  from  the  ground  station  is  not  finalized.  The  final 
requirement  NT-3  describes  how  the  propagators  must  be  able  to  predict  communications 
intervals  for  one  week  in  the  presence  of  no  thrust.  This  is  important  to  ensure  that  if  the 
satellite  needs  to  be  pointed  to  the  ground  during  normal  operations,  that  the  propagator 
knows  when  the  ground  station  will  be  in  view.  One  week  without  DCFT  operations 
should  be  sufficient  to  uplink  TLEs  to  update  the  satellite’s  new  state. 

2. 1.3.3  THERMAL  TASK 
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The  thermal  software  task  requirements  are  outlined  below.  Further  work  will  be  done  to 
detail  the  design  to  meet  these  requirements. 

TT-1  The  thermal  software  shall  monitor  temperatures  of  components  and  identify  any 
components  that  are  out  of  desired  operational  range. 

TT-2  The  thermal  task  shall  inform  the  operations  software  if  the  thermal  conditions  of 
critical  components  are  outside  the  accepted  range. 


These  requirements  illustrate  the  need  for  much  more  defined  software  requirements 
preceding  the  algorithm  of  the  task.  There  are  many  types  of  ways  to  inform  the 
operations  software,  so  a  detailed  plan  must  be  agreed  upon  between  the  thermal  team 
and  operations  team  to  ensure  that  the  satellite  will  survive  in  all  operational  cases.  The 
thermal  sensor  files  will  be  created  in  either  the  operations  task  or  the  data  collection  and 
storage  task.  The  thermal  team  will  be  responsible  for  providing  the  thermal  task 
algorithm,  as  well  as  testing  the  final  software  product. 


2. 1.3.4  ADCS  TASK 

AT-1  The  ADCS  software  shall  determine  the  attitude  of  the  spacecraft  with  respect  to 
the  inertial  and  orbital  reference  frames  at  any  time. 

AT-2  The  ADCS  software  shall  point  the  satellite  in  the  desired  direction  to  detumble 
body  rates,  generate  power,  point  the  thrust  vector,  or  communicate  with  the  ground. 

AT-3  The  ADCS  task  shall  have  the  capability  of  collecting  sensor  data,  calculated  data, 
and  actuator  data  and  send  the  data  back  to  the  ground. 

The  ADCS  task  interacts  with  the  operations  and  navigation  tasks  to  ensure  that  the 
satellite  is  pointed  where  it  is  supposed  to  be.  The  attitude  determination  algorithms  and 
processing  (Kalman  filters)  will  take  place  in  this  task.  AT-1  and  AT-2  are  the  general 
requirements  that  the  attitude  system  needs  to  meet  for  CASTOR.  No  error  values  are 
associated  with  these  software  tasks;  however,  the  amount  of  error  will  factor  into  the 
decision  to  operate  the  DCFT.  AT-3  is  the  interface  between  the  ground  analysis  tools 
and  the  satellite  data  packaging.  The  ADCS  team  will  determine  what  scope  AT-3  entails 
and  how  much  detail  they  will  want  to  be  collected. 

2. 1.3.5  ADDITIONAL  TASKS 

The  EPS,  Communications,  and  Propulsion  system  tasks  still  need  to  be  analyzed  and  the 
requirements  written.  Additionally,  the  high-level  communication  task  may  or  may  not 
actually  be  placed  in  the  satellite  software  architecture,  as  most  communications 
functions  are  inherent  in  the  baseline  software. 


2. 1 .4  FLATS  AT  OPERATIONS  AND  TESTING  (K.  ANDERSON) 
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The  CASTOR  satellite  must  undergo  extensive  testing  to  create  mission  assurance. 
Mission  assurance  is  defined  as  the  general  system  engineering,  quality,  and  management 
principles  towards  the  goal  of  achieving  mission  success,  and,  toward  this  goal,  provides 
confidence  in  its  achievement.  Mission  success  is  defined  as  the  achievement  of  a  system 
to  singularly  or  in  combination  meet  not  only  specified  performance  requirements,  but 
also  expectations  of  the  users  and  operators  in  terms  of  safety,  operability,  suitability,  and 
supportability.  Mission  assurance  focuses  on  the  detailed  engineering  of  the  acquired 
system,  and,  toward  this  objective,  uses  independent  technical  assessments  as  a 
cornerstone  throughout  the  entire  concept  and  requirement  definition,  design, 
development,  production,  test,  deployment,  and  operation  phases. 


There  are  three  key  reasons  why  a  test  should  be  performed.  These  reasons  and  the 
rationale  behind  them  are  listed  below. 

1  Functionality  verification 

1.1  Evaluate  that  the  as-built  system  (including  interfaces)  satisfies  the 
requirements  and  specification  baseline. 

1.2  Identify  issues  with  the  proposed  test,  integration,  and  verification  plans  and 
procedures 

2  Reduce  Risk 

2.1  Evaluate  appropriateness  and  risk  of  verification  by  any  method  other  than 
testing. 

2.2  Evaluate  risks  associated  with  deviations  from  environmental  testing 
standards  (e.g.,  MIL-STD  1540)  and  other  applicable  standards  or  best 
practices. 

2.3  Evaluate  the  fidelity  to  the  “test  like  you  fly”  (TLYF)  and  “test  what  you  fly” 
philosophies,  especially  at  the  system  and  higher  levels  of  integration,  and 
identify  risks  associated  with  deviations  from  these  philosophies.  This 
includes  implications  to  accurate  modeling  and  simulation. 

3  Unfamiliar  Area 

3.1  Evaluate  analysis,  simulation,  inspection,  and  test  results  to  determine 
readiness  to  proceed  to  subsequent  test  or  program  activities. 


All  testing  will  follow  begin  at  the  component  level,  progress  through  the  subsystem 
level,  and  finish  at  the  assembly  level.  There  may  be  additional  tests  between  the  three 
major  levels,  but  as  a  minimum,  all  aspects  of  the  design  will  be  tested  in  this  order  for 
the  reasons  listed  above. 


2.1.5  GNC  DESIGN  (D.  DELATTE) 

The  GNC  design  is  currently  proposed  to  consist  of  two  major  navigational  aides:  a  GPS 
receiver  and  an  on-board  orbital  propagator.  Neither  of  these  has  been  analyzed  fully  this 
semester,  although  the  current  GPS  receiver  picked  is  the  same  from  the  previous  class 
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(SGR-05).  The  on-board  orbital  propagator  will  utilize  the  SGP4  propagation  technique, 
which  propagates  Two  Line  Elements  (TLEs)  forward  in  time.  The  TLEs  would  be 
uploaded  from  the  ground  station.  The  nominal  operations  include  using  the  GPS  as  the 
primary  navigation  tool  and  having  the  on-board  propagator  as  a  backup  as  well  as  look¬ 
ahead  for  scheduling. 


2.1.6  INTEGRATED  MODELING  (J.  ROBINSON) 


A  CASTOR  systems  model  is  being  developed  to  predict  the  expected  state  and  behavior  of 
the  CASTOR  system.  At  the  end  of  this  development  process,  an  integrated  model  will  exist 
that  can  serve  two  purposes: 

•  Predict  the  expected  states  and  maneuvers  of  CASTOR 

•  Compare  actual  behavior  with  expected  behavior 

•  Track  DCFT  performance/fulfillment  of  mission  objectives 

•  Aid  design  decisions  and  different  operational  mode  analysis 

The  first  purpose  of  predicting  the  expected  CASTOR  behavior  will  be  important  to  ensure 
that  once  on-orbit,  the  CASTOR  operations  team  has  full  control  over  the  vehicle  and  can 
provide  any  interested  parties  with  the  future  predicted  state  of  CASTOR.  The  CASTOR 
vehicle  does  not  have  a  large  amount  of  thrust  capabilities,  so  even  with  large  amount  of 
prediction  errors,  the  CASTOR  state  can  be  controlled,  given  the  assumption  that  the  satellite 
does  not  maneuver  autonomously  if  it  does  not  hear  from  the  ground  station.  The  second 
purpose  of  the  integrated  model  will  be  to  feed  in  the  CASTOR  commands  to  the  simulation 
and  show  how  the  systems  are  interacting  with  each  other.  After  calibration  in  the  initial 
stages  of  commissioning  and  early  normal  operations,  this  tool  will  allow  operators  to  see 
any  divergence  from  the  expected  behavior,  and  thus  enable  operators  to  identify  future 
problems  or  failures  before  they  intensify. 

This  integrated  model  will  be  used  to  characterize  and  track  the  DCFT‘s  performance  with 
time  to  fulfill  its  mission  objectives.  The  total  firing  time  of  the  engine  and  the  realized  total 
delta-V  are  the  main  outputs  of  the  mission,  but  the  integrated  model  will  allow  vehicle  errors 
(pointing  or  navigation)  to  be  incorporated  to  get  a  better  representation  of  the  DCFT‘s 
performance. 


2.2  ACS  DESIGN  (D.  DELATTE) 

The  role  of  the  Attitude  Determination  and  Control  System  (ACS)  is  to  determine  and 
control  the  orientation  of  the  spacecraft.  The  current  sensor  architecture  consists  of  a 
space-qualified  GPS  system  to  determine  position,  a  set  of  four  space  qualified  sun 
sensors,  a  three-axis  inertial  measurement  unit  (IMU),  and  a  magnetometer  to  determine 
attitude.  The  actuator  architecture  consists  of  three  orthogonal,  space-qualified  reaction 
wheels  to  control  about  each  of  the  three  axes  and  three  orthogonal  torque  coils  to  de- 
saturate  the  reaction  wheels  and  provide  redundant  control  authority.  This  version  of  this 
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spacecraft  is  designed  to  operate  in  low  earth  orbit  (LEO),  as  opposed  to  the  previous 
version,  which  was  designed  to  operate  from  geosynchronous  orbit  (GEO)  out  to  the 
moon.  Therefore,  torque  coils  can  be  used  for  desaturation  in  place  of  the  nitrogen 
thruster  system.  The  concept  of  operations  and  the  external  torque  environment  is  a 
driving  factor  in  the  design  of  the  spacecraft  ACS  architecture.  The  spacecraft  will 
experience  disturbance  torques  from  the  strong  engine  magnet,  aerodynamic  drag,  solar 
pressure,  and  the  gravity  gradient  due  to  its  proximity  to  the  earth.  Moreover,  the  satellite 
must  be  able  to  deal  with  the  challenges  imposed  by  eclipse,  during  which  attitude 
estimation  would  be  limited  to  the  magnetometer  and  IMU,  power  is  constrained,  and  the 
control  sequence  will  be  limited.  Finally,  operation  in  low  earth  orbit  (LEO)  allows  use 
of  GPS  for  position  and  velocity  determination. 

The  design  of  the  spacecraft  ACS  system  must  meet  several  requirements.  First,  the 
spacecraft  must  orient  the  main  engine  to  point  in  the  direction  specified  by  the  desired 
orbit,  parallel  to  the  velocity  direction.  The  primary  goal  of  the  main  engine  is  to  show  a 
change  in  velocity.  Therefore,  the  main  engine  must  be  oriented  either  in  line  with  or 
opposite  the  velocity  vector.  Any  inaccuracy  in  this  pointing  will  result  in  a  decrement  of 
directional  thrust  efficiency  and  thus  a  loss  in  delta  V.  The  thrust  requirement  is  to 
achieve  97%  time-averaged  directional  thrust  efficiency.  Secondly,  the  spacecraft  must 
orient  the  solar  panels  in  the  direction  of  the  sun,  so  that  the  sun’s  rays  strike  normal  to 
the  frontal  area  of  the  deployed  solar  panels.  During  the  engine’s  operational  phase,  the 
solar  panels  can  only  be  turned  toward  the  direction  of  the  sun  by  changing  the  attitude  of 
the  satellite  about  the  x-axis.  During  the  battery-charging  phase,  the  solar  panels  will  be 
aligned  normal  to  the  sun.  As  with  the  engine,  an  inaccuracy  in  this  pointing  will  result 
in  a  loss  of  power  generation.  The  power  generation  pointing  requirement  is  to  maintain 
97%  efficiency  in  solar  energy  generation  due  to  pointing,  which  is  an  angle  error  of  14°. 
Finally,  the  spacecraft  must  be  controlled  for  its  designed  mission  length  of  twelve 
months. 

To  maintain  these  efficiencies,  the  instantaneous  orientation  of  the  spacecraft  must  be 
known  in  order  to  actuate  the  spacecraft  to  the  reference  orientation.  Based  on  common 
ADCS  performance  from  SMAD,  the  ratio  needed  between  actuation  accuracy  and 
estimation  accuracy  is  five  to  one.  Since  the  overall  pointing  actuation  requirement  is  set 
at  five  degrees,  it  was  determined  that  the  appropriate  attitude  estimation  accuracy  is  one 
degree  in  each  axis.  To  accomplish  this  task,  a  sensor  suite  of  four  sun  sensors  and  one 
magnetometer  is  selected  for  the  design.  The  IMU  is  needed  to  integrate  rates  to 
determine  attitude  during  periods  of  unavailable  sensor  readings.  The  need  to  reliably  use 
a  magnetometer  places  a  requirement  on  position  accuracy.  The  magnetometer  requires 
knowledge  of  position  to  determine  the  true  magnetic  field  vector  in  order  to  compare  the 
vector  of  the  magnetometer  reading  with  the  local  magnetic  field  from  the  International 
Geomagnetic  Reference  Field  (IRGF)  model  vector  and  thus  obtain  attitude  vector 
equivalence.  The  position  requirement  is  derived  from  an  analysis  of  how  an  error  in 
position  determination  creates  an  error  in  attitude  estimation.  A  position  estimation  error 
when  the  spacecraft  is  along  the  equator  will  have  the  largest  impact  on  the  attitude  error. 
The  magnetic  field  has  the  highest  gradient  with  respect  to  latitude  around  the  equator, 
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while  changes  in  longitude  have  little  effect.  As  latitude  increases,  the  gradient  with 
respect  to  latitude  direction  decreases.  The  analysis  done  compares  the  direction  of  the 
modeled  magnetic  field  vector  at  one  point  on  the  equator  with  the  direction  of  the 
modeled  magnetic  field  vector  with  some  latitude  error.  The  angle  between  the  two 
vectors  obtained  by  a  dot  product  gives  the  attitude  error.  The  attitude  error  is  assumed  to 
be  a  linear  function  of  error  in  latitude,  which  makes  use  of  the  linearization  of  the  sine 
function  for  small  angles.  If  the  attitude  error  from  the  magnetometer  is  constrained  to  0.1 
degrees,  there  is  a  reference  input  error  of  166  arc  seconds  (0.05  degrees).  Given  the 
assumption  that  the  earth’s  magnetic  field  has  been  perfectly  modeled,  converting  to  units 
of  distance  gives  5.7  km  of  allowable  position  error  in  the  north-south  direction  to 
maintain  an  attitude  estimate  to  0.1  degrees.  Selecting  0.1  degrees  leaves  margin  for  both 
fluctuations  in  the  earth  magnetic  field  and  lack  of  accuracy  of  magnetometer  output. 

This  causes  error  in  aligning  the  engine  with  the  velocity  vector.  If  the  spacecraft 
estimates  its  position  with  some  error,  the  reference  thrust  vector  input  to  the  ACS  system 
will  be  sub-optimal:  the  latitude  or  longitude  error  will  be  equal  to  the  error  in  reference 
input.  Therefore,  the  166  arc  second  (0.05  degrees)  reference  input  error  mentioned 
earlier  will  lead  to  an  acceptable  additional  0.05  degrees  in  attitude  error. 

The  ACS  control  torque  magnitudes  are  sized  so  that  the  satellite  is  capable  of 
completing  required  state  changes  over  each  orbit.  In  addition,  the  solar  panels  must  re¬ 
acquire  the  sun  quickly  (time  «  period  in  sunlight)  after  re-entering  sunlight.  The 
requirement  on  update  frequency  was  based  on  the  stability  of  the  designed  control 
system  (detail  in  2.3.5).  The  ACS  torque  requirement  is  based  on  a  worst  case 
disturbance  torque  build-up  over  two  orbits  and  the  capability  for  re-orientation  within  10 
minutes.  The  following  is  the  full  set  of  ADCS  requirements: 

1.  ACS 

1.1.  ACS  shall  estimate  and  control  the  attitude  of  the  spacecraft  body  to 
point  the  thrust  vector  such  that  97%  of  the  thrust  is  in  the  commanded 
direction. 

1.2.  ACS  shall  estimate  the  attitude  of  the  spacecraft  body  to  1  degree  of  its 
true  attitude  in  all  3  axes. 

1.3.  ACS  shall  control  spacecraft  attitude  to  5°  of  a  reference  input  in  all  3 
axes. 

1.4.  ACS  shall  be  able  to  control  the  spacecraft  attitude  through  a  dynamics 
range  of  360°  in  all  3  axes. 

1.5.  ACS  shall  be  able  to  perform  a  180°  slew  on  the  spacecraft  body  within 
10  min. 

1.6.  ACS  shall  perform  a  spacecraft  attitude  estimate  and  control  at  a  rate  of  1 
Hz. 

1.7.  ACS  shall  be  able  to  reduce  angular  rates  to  a  manageable  magnitude 
during  initial  deployment  and  departure  from  eclipse. 

1.8.  ACS  shall  be  able  to  apply  a  torque  of  0.033  N-m  during  de-tumble. 

2.  Longevity 


16.83  CASTOR  Design  Document 


Page  60 


November  18,  2010 


2.1.  All  ACS  components  shall  survive  launch  loads. 

2.2.  All  ACS  components  shall  function  for  12  months  of  spacecraft 
operation. 


2.2.1  BUDGET  (D.  DELATTE) 

Attitude  determination  and  control  functionality  is  critical  in  order  to  communicate  with 
and  operate  the  spacecraft.  In  order  to  design  a  lean,  yet  reliable  determination  and 
control  system,  several  architectures  fitting  in  weight  restraints  of  the  University 
Nanosatellite  Program  (UNP)  were  considered,  and  the  system  detailed  in  the  sections 
below  was  selected  for  its  reliability,  constructability,  and  low  relative  cost. 


Component 

Units 

Total  Power  (W) 
Nominal  Power 

Peak  Power 

Total  Mass  (kg) 

Total  Cost  ($) 

Sun  Sensor 

4 

0.1 

0.3 

0.136 

48000 

Magnetometer 

1 

0.0024 

0.003 

0.022 

480 

Reaction  Wheel 

3 

1.5 

21 

0.675 

90000 

Torque  Coil 

3 

3 

6 

0.75 

750 

IMU 

1 

0.165 

0.285 

0.02 

620 

GPS  Unit 

1 

0.5 

0.8 

0.02 

23010 

GPS  Antenna 

1 

0.012 

Magnet 

1 

0.25 

2000 

Total 

5.2674 

28.388 

1.885 

164860 

TABLE  2.2. 1-1:  ACS/GNC  COMPONENT  BUDGET 


2.2.2  DESIGN  CAPTURE  (D.  DELATTE) 


The  goal  of  the  ACS  system  was  to  optimize  the  system’s  mass  and  dollar  cost 
parameters  while  fulfilling  requirements.  The  ACS  system  is  designed  to  have  a  large 
amount  of  redundancy  to  mitigate  risk  and  work  closely  with  a  number  of  other 
subsystems.  The  requirements  are  driven  by  the  needs  of  the  payload,  the  DCFT.  The 
torque  coils  de-saturate  the  reaction  wheels  and  could  be  used  to  turn  the  satellite  if 
needed  (albeit  much  more  slowly).  The  following  points  were  considered:  magnitudes 
and  time-domain  profiles  of  external  disturbance  torques,  typical  range  of  inclinations 
within  which  the  spacecraft  will  operate,  characteristic  rotational  speeds,  and  vehicle 
moments  of  inertia.  The  following  paragraphs  expand  on  various  aspects  of  the  design  for 
the  torque  disturbances,  vehicle  inertias,  and  controller  design. 

By  simulation  of  the  torque  disturbances  over  a  typical  orbit  and  the  attitude  maneuvers 
of  the  orbit,  the  reaction  wheel  max  torque  is  set  to  60  mNm,  which  is  enough  to  correct 
for  instantaneous  and  time-averaged  disturbance  torques  as  well  as  slewing. 
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The  design  of  the  spacecraft  has  assumed  orbits  inclined  between  0  and  +60  degrees 
relative  to  the  earth's  equatorial  plane.  The  controller  design  shall  be  robust  to  inclination 
variation  by  being  able  to  handle  the  worst-case  disturbance  torques  (magnetic)  and  the 
worst-case  sunlight  to  eclipse  ratios  (ecliptic,  50%)  throughout  this  inclination  range.  The 
controller  uses  consumable  actuation  in  the  form  of  reaction  wheels  storing  angular 
momentum  for  torque  control.  When  one  of  the  reaction  wheels  reaches  a  speed  near 
saturation,  magnetic  torque  coils  will  turn  on  to  provide  an  external  torque  on  the  satellite 
and  remove  the  stored  momentum  in  the  reaction  wheel.  The  cycle  of  attitude  control 
with  reaction  wheels  and  de-saturation  with  torque  coils  is  a  sustainable  process  under  the 
current  concept  of  operations. 

Vehicle  inertias,  as  provided  in  the  structures  section  indicate  that  the  spacecraft,  with  no 
actuation  over  the  cycle  of  one  orbit  would  change  attitude  arbitrarily  over  the 
characteristic  period  of  approximately  90  minutes.  From  the  start  of  sunlight  entry,  the 
reaction  wheels  are  able  to  orient  and  control  the  spacecraft  over  a  period  of 
approximately  10  minutes.  This  period  may  be  shortened  if  limited  or  full  control  is 
implemented  during  eclipse. 


2.2.3  HARDWARE  AND  ARCHITECTURE  (S.  VEGA) 


FIGURE  2.2-1:  HARDWARE  AND  SOFTWARE  SCHEMATIC 
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As  can  be  seen  in  the  above  figure,  the  CASTOR  ADCS  hardware  selection  can 
be  divided  into  two  parts:  sensors  (left  side)  and  actuators  (right  side).  The  sensors 
consist  of  a  space-rated  GPS  receiver,  one  three-axis  magnetometer,  four  two-axis  sun 
sensors,  and  a  three-axis  IMU  for  short  term  angular  rate  and  acceleration  measurements. 
Detailed  specifications  for  each  of  these  instruments,  including  operational  parameters, 
mounting  instructions,  data  and  power  needs  can  be  found  in  the  appendices.  The 
magnetometer,  along  with  the  sun  sensor,  provides  the  primary  reference  for  attitude 
determination.  The  GPS  unit  provides  precision  position  and  linear  velocity  information. 
The  position  information  is  used  to  determine  the  expected  local  magnetic  field  of  the 
Earth  from  an  on-board  look-up  table  and  uses  this  to  determine  attitude  information 
from  the  magnetometer.  The  sun  sensors  provide  the  missing  information  not  available 
from  the  magnetometers.  The  IMU  is  used  to  determine  angular  rate  information  during 
the  initial  de-tumble  and  during  slews.  Some  amount  of  linear  acceleration  information 
can  also  be  determined  if  this  is  caused  due  to  gas  leaks  in  the  main  engine  pressure  lines. 
The  IMU  can  be  used  to  determine  linear  acceleration  due  to  the  main  engine,  but  it  is  not 
the  primary  purpose  of  the  IMU. 

The  actuators  consist  of  three  0.12  Nms  momentum  storage  capable  reaction 
wheels  with  a  continuous  torque  greater  than  5  mNm.  These  reaction  wheels  have  been 
chosen  to  provide  enough  momentum  storage  capability  to  offset  the  disturbances  from 
external  torques  and  maintain  attitude  control  during  slew  maneuvers  over  one  orbit 
without  de-saturation.  Three  torque  coils  with  a  maximum  dipole  of  3  AmA2  are  used  to 
de-saturate  the  reaction  wheels.  Given  a  nominal  orbital  position  of  the  satellite,  the 
torque  coils  can  fully  de-saturate  the  reaction  wheels  in  approximately  30  minutes. 

Each  sensor  and  actuator  is  chosen  to  comply  with  or  exceed  one  of  the 
requirements  listed  in  the  section  above.  This  relationship  between  the  requirements  and 
the  hardware  components  is  provided  below.  The  numbering  scheme  is  the  same  as  that 
used  for  the  requirements  section  above. 

1.  ACS 

1.1.  Results  from  the  control  law  simulation  which  includes  all  sensors  and 
actuators  and  accounts  for  signal  noise  as  well  as  realistic  estimators  and 
filters  show  that  the  engine  thrust  pointing  is  correct  for  over  97.5%  on 
average. 

1.2.  Estimator  error  with  manufacturer  specified  noise  and  error  levels  for 
magnetometer  is  0.6°.  The  sun  sensors  must  be  characterized  to 
determine  estimator  error. 

1.3.  Simulation  shows  that  control  within  5°  of  reference  value  can  be 
achieved  in  operation. 

1.4.  ACS  reaction  wheels  provide  rotational  movement  about  all  3  axes  for 
360°;  redundancy  is  achieved  by  using  the  torque  coils  for  attitude 
control. 

1.5.  ACS  is  able  to  provide  full  range  state  change  in  10  minutes  based  on 
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calculated  actuator  forces  and  torques  and  spacecraft  mass  and  inertia 
properties  obtained  from  the  CAD  model  created  by  the  structures  team. 

1.6.  Attitude  estimate  at  a  rate  of  1  Hz  is  performed  by  the  estimator.  Attitude 
sensors  update  at  frequencies  at  or  higher  than  5  Hz  each.  The  GPS 
information  is  updated  at  5  Hz. 

1.7.  ACS  torque  coils  able  to  de-tumble  initially  since  they  can  apply  external 
torque  on  the  satellite.  De-tumble  on  eclipse  exit  is  performed  by  the 
reaction  wheels. 

1.8.  ACS  able  to  provide  torque  of  0.01  Nm  if  required. 

2.  Longevity 

2.1.  Non-space-rated  components  have  specified  loading  thresholds  in 
relevant  directions  less  than  launch  loads  specified  by  ESPA. 

2.2.  All  ACS  components  have  specified  lifecycle  times  exceeding 
requirements. 


SUN  SENSOR  DATA 

The  CASTOR  satellite  will  have  four  sun  sensors,  which  will  detect  the  position 
of  the  sun.  For  this  project,  we  are  using  the  SS-41 1  ’s  ±70°  field  of  view.  The  abilities  of 
different  varieties  of  sun  sensors  to  have  the  accuracy  and  specifications  greatly  impacted 
the  decision  process.  The  SS-41 1  Two-Axis  Digital  Sun  Sensor  by  Sinclair  Interplanetary 
has  0.03  kg  of  mass,  and  uses  .0750-Watts  max  power.  This  component  is  space  rated. 

The  price  of  each  sun  sensor  has  increased  to  $12,000.  Having  four  sun  sensors 
reduces  the  number  of  blind  spots  on  the  satellite,  but  it  is  currently  uncertain  whether  the 
budget  will  allow  for  the  unexpected  increase  in  necessary  funding. 

The  sun  sensor’s  task  is  to  determine  the  vector  to  the  sun.  Each  SS-41 1  will 
return  a  three-  component  vector  (from  the  satellite  to  the  sun),  which  will  tell  the  control 
law  how  to  turn  the  satellite  in  order  for  the  solar  panels  to  be  orthogonal  to  the  sunlight. 
Having  four  sun  sensors  will  give  greater  coverage  of  the  satellite  and  allow  the  position 
to  be  determined  quickly.  Should  one  or  more  (but  not  all)  sun  sensors  fail,  the  reaction 
wheels  could  be  used  to  rotate  the  satellite  until  the  sun’s  position  is  detected.  This  would 
be  less  efficient,  but  it  is  a  viable  back  up  plan.  If  all  sun  sensors  fail,  the  GPS  alone  can 
provide  the  sun  vector  (the  position  in  latitude/  longitude/  altitude  provided  by  GPS  can 
be  used  to  determine  when  the  satellite  enters  or  exits  eclipse)  or  the  reaction  wheels 
could  be  used  to  turn  the  satellite  so  that  the  solar  panels  could  get  some  time  in  view  of 
the  sun.  This  would  not  be  an  efficient  use  of  power  and  is  extremely  unlikely,  but  this 
backup  would  keep  the  mission  from  failing. 

Although  the  sun  sensors  cannot  be  purchased  until  after  this  spring  semester 
(thus  delaying  testing),  an  engineering  model  should  be  acquired  with  the  correct 
connectors  in  order  to  demonstrate  the  placement  and  links  of  the  sun  sensor. 

Part  Name:  SS-41 1  Two-Axis  Digital  Sun  Sensor 
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Manufacturer:  Sinclair  Interplanetary 

Contact:  (647)  286-3761  voice,  (775)  860-5428  fax,  dns  @  sinclairinterplanetary.com 


Accuracy 

±0.1°  over  ±70°  Field-of-View 

Earth  Albedo  Error 

Rejected  by  internal  digital  processor 

Bandwidth 

5  vector  solutions  /  second 

Command  /  Telemetry 

UART,  SPI,  I2C  or  CAN 

Mechanical 

34  mm  x  32  mm  x  21  mm,  34  g  mass 

Outer  Surfaces 

Low  emissivity  gold,  scratch-proof  sapphire 

Supply  Voltage 

4.0  to  50.0  V 

Supply  Current 

5.0  mA  avg,  15.0  mA  peak 

Temperature 

-25°C  to  +70°C  operating 

Space  Heritage 

14  Sensors  on-orbit  on  4  LEO  missions 

TABLE  2.2-2:  SUN  SENSOR  CHARACTERISTICS 

INERTIAL  MEASUREMENT  UNIT  DATA 

The  IMU  chosen  for  CASTOR  is  the  ADIS  16365  by  Analog  Devices.  The  IMU’s 
component  success  will  be  determined  according  to  whether  it  meets  the  required 
specifications  necessary  for  the  CASTOR  satellite  and  whether  it  correctly  interfaces 
with  the  other  components.  From  resources  allotment,  the  IMU  must  draw  max  0. 1650 
Watts  and  have  a  mass  under  0.02  kg.  The  selected  part  complies  with  these 
requirements. 

The  rate  sensor  will  be  tested  using  the  SPI  with  a  32-bit  Windows  operating  system. 
Prior  analysis  has  indicated  that  the  communication  works,  but  the  accuracy  needs  to  be 
determined.  A  rate  table  will  be  used  to  determine  the  static  rate  and  this  value  will  be 
compared  to  the  output  of  the  IMU.  In  an  ideal  situation,  this  component  would  be  tested 
on  the  air  bearing,  but  it  is  currently  uncertain  exactly  when  that  will  be  completed.  In  the 
meantime,  the  rate  table  is  an  excellent  option. 

Part  Name:  ADIS  16365 

Manufacturer:  Analog  Devices,  Contact:  (781)  329-4700, 


16.83  CASTOR  Design  Document 


Page  65 


November  18,  2010 


(781)  461-3113  fax,  www.analog.com 


Characteristic 

Value 

Performance 

Measurement  Range 

±10  g 

Resolution 

14-bit 

Bandwidth 

350  Hz 

Physical  Envelope 

Mass 

TBD 

Thermal 

Operating  Temperature 

Range 

-40°C  to  +85  °C 

Power 

Operation 

5  V  +  0.25  V 

Normal  Mode  at  25°  C 

33  mA 

Fast  Mode  at  25°  C 

57  mA 

Sleep  Mode  at  25°  C 

500  pA 

TABLE  2.2-3:  MEMS  IMU  RATE  SENSOR 


MAGNETOMETER  DATA 

The  Micro-Mag3  3-axis  magnetometer  takes  a  3-axis  vector  reading  of  Earth’s  local 
magnetic  field  which  will  be  compared  to  the  International  Geomagnetic  Reference  Field 
(IRGF)  model  vector  in  order  to  determine  attitude.  Accurate  attitude  estimation  is 
necessary  to  be  able  to  actuate  the  satellite  from  its  current  orientation  to  the  reference 
orientation. 


The  ACS  magnetometer  group  has  successfully  connected  the  Micro-Mag3 
magnetometer  via  the  PNI  communication  board  and  collected  data  from  the 
magnetometer  using  the  CommBoard  Studio  graphical  user  interface  (GUI),  thereby 
completing  acceptance  testing.  The  measurements  from  the  magnetometer  have  also  been 
correlated  to  the  corresponding  magnetic  field  measurements.  The  correlation  is  as 
follows:  (measurement  +  offset )  *  scale=  field  strength 

where  the  offset=-15  and  the  scale=-0.00025.  This  information  is  not  provided  by  the 
manufacturer. 
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Component  testing  will  aim  to  prove  that  the  magnetometer  is  capable  of  meeting 
accuracy  requirements.  The  ACS  requirement  for  attitude  determination  is  within  1 0  of 
accuracy  in  each  axis.  To  determine  this  capability,  the  magnetometer  will  be  tested  in  a 
magnetic  field  created  by  a  Helmholtz  coil,  so  that  the  1-axis  magnetic  field  vector  is 
known.  When  placed  between  the  coils,  the  reading  from  the  magnetometer  should  then 
confirm  the  known  magnetic  field,  showing  a  vector  component  of  the  field  in  one  axis. 
ACS  will  also  be  able  to  rotate  the  magnetometer  to  specified  angles  to  confirm  the 
correct  vector  component  measurements  in  each  axis,  testing  how  accurately  the 
magnetometer  estimates  the  known  magnetic  field  vector.  This  test  will  inform  ACS  as  to 
what  accuracy  the  magnetometer  is  capable  of  predicting  the  magnetic  field’s  location. 

Once  this  test  is  completed,  the  next  stage  of  testing  will  be  to  test  the  component  on  the 
air  bearing  test  bed,  using  the  SPHERES  satellite  to  give  a  true  attitude  reading  to 
compare  to  the  reading  from  the  magnetometer.  A  larger  Helmholtz  coil  is  also  being 
constructed  around  the  air  bearing,  such  that  a  similar  test  to  the  tabletop  Helmholtz  coil 
test  can  be  run  on  the  air  bearing  with  greater  degrees  of  freedom  available  to  position  the 
magnetometer.  ACS  will  create  an  estimation  process  for  the  magnetometer  readings  to 
attain  this  accuracy. 

Part  Name:  MicroMag3  (Part  #  12349) 

Manufacturer:  PNI  Corporation 


Contact:  707-566-2266  phone,  email:  sales@pni.corp,  web:  www.pnicorp.com 


Characteristic 

Value 

Performance 

Large  Field  Measurement 
Range 

±1100  pT 

High  Resolution  Field 
Measurement 

0.01 5  pT 

Fast  Sample  rate 

Up  to  2000  Hz 

Physical  Envelope 

Mass 

10  g  (estimate) 

Thermal 

Operating  Temperature 

Range 

-20°  to  70°  C 

Power 

Operation 

3V 

Max  DC  Supply  Voltage 
(Vdd) 

5.25  VDC 

Max  Input  Pin  Voltage 

VDD  +  0.3  VDC 

Max  Input  Pin  Current 

10.0  mA  at  25°C 
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TABLE  2.2-4:  MAGNETOMETER  CHARACTERISTICS 


GPS  UNIT  DATA 

The  Surrey  Satellite  Technology  Ltd  SGR-05U  Space  GPS  Receiver  is  capable  of 
providing  standard  GPS  time  in  addition  to  position  and  velocity  readings  that  can  infer 
orbit  determination. 

The  component  is  however  extremely  expensive  and  thus  is  yet  to  be  purchased. 

However  the  GPS  compent  has  great  deal  of  flight  heritage  and  requires  testing  briefly  to 
utilize  it. 

Part  Name:  SSTL  SGR-05U 


Manufacturer:  Surrey  Satellite  Technology  Ltd 

Contact:  +44(0)1438  803803  phone,  +44(0)1438  803804  fax, 

email:  info@sstl.co.uk,  web:  www.sstl.co.uk 


Characteristic 

Value 

Performance 

Time  (UTC) 

1  ps 

Position 

10  m 

Velocity 

0.15  ms'1 

Dynamic  Capability 

8  kms"1,  2g 

Physical  Envelope 

Mass 

20  g 

Thermal 

Operating  Temperature 

Range 

0°  to  50°  C 

Power 

Operation 

0.5-0. 8  W  @  5  V 

Environmental 

Vibration  (acceptance  level) 

15  g  rms 

Table  2.2-5:  Space  GPS 

TORQUE  COIL  DATA 
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When  in  orbit,  the  3  torque  coils  will  act  as  momentum  dumpers  to  desaturate  the  3 
reaction  wheels.  In  operation  of  the  satellite,  angular  momentum  will  stored  up  in  the 
reaction  wheels.  When  the  angular  momentum  of  the  satellite  as  well  as  the  speed  of 
rotation  of  the  reaction  wheels  verges  on  the  maximum  desired  value,  it  is  said  to  be 
saturated.  It  is  at  this  point  that  the  torque  coils  are  needed  to  provide  an  external  torque 
that  desaturates  the  reaction  wheels  by  dumping  the  angular  momentum  stored  up  onto 
the  earth  by  torquing  against  the  earths  magnetic  field.  The  torque  coils  are  required  to 
provide  this  function  within  one  orbit.  Desaturation  of  the  satellite  should  only  occur 
when 

The  torque  coils  are  being  built  in  house  and  are  sized  to  be  able  to  desaturate  the 
reaction  wheels  within  approximately  one  orbit.  Based  on  the  reaction  wheel  momentum 
storage  capability,  the  torque  coils  should  have  a  magnetic  dipole  of  approximately  3 
AmA2.  The  coils  will  be  built  in  house  using  32  gauge  copper  magnet  wire.  There  will 
be  three  torque  coils  placed  on  the  satellite  and  each  of  these  coils  must  be  located 
orthogonal  to  each  other  in  order  to  provide  sufficient  torque  capability.  Two  of  the  coils 
will  be  placed  along  the  perimeter  of  the  frames  on  the  sides  and  the  third  coil  will  be 
placed  on  the  top  frame,  as  shown  in  Figure  2.2.32:  Torque  coil  layout  (top)  and  Figure 
2.2.33:  torque  coil  layout  (side).  The  following  description  gives  the  details  of  the  coils 
that  will  be  placed  along  the  structure.  The  magnetic  dipole  of  a  wire  coil  is  given  by  the 
equation:  u  =  A*i*n  where: 

u  =  magnetic  dipole  (AmA2)  A  =  enclosed  area  (mA2) 

i  =  current  (A)  n  =  number  of  turns  of  wire 

The  outside  frames  have  rectangular  shapes  allowing  the  torque  coil  design  to  have 
rectangular  geometries  of  sides  roughly  measuring  at  30  by  43cm  on  the  sides  and  43  by 
43  cm  on  the  top.  The  coil  will  be  lined  along  the  inside  face  of  the  frames. 
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FIGURE  2. 2. 3-3:  TORQUE  COIL  LAYOUT  (SIDE) 
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The  torque  coils  on  the  side  provide  desaturation  along  the  y  and  z  axis.  After 
optimization  calculations  the  desired  specifications  have  an  enclosed  area  of  0.129  mA2. 
In  order  to  minimize  power  use  and  stay  within  the  limitations  of  32  gauge  copper  wire 
chosen,  the  current  has  been  chosen  to  be  0.05  A.  This  leaves  the  number  of  turns  to  be 
466.  This  gives  a  total  length  of  680.4m  of  coil  in  each  case  and  a  power  rating  of  1 .57 
W.  In  order  to  mount  the  coil,  the  use  of  straps  will  be  used  initially.  If  this  is  not 
sufficient  for  vibration  testing  a  more  permanent  attachment  such  as  hooks  may  be  used. 
The  straps/hooks  will  be  spaced  in  a  manner  to  increase  the  fundamental  frequency  of  the 
coils  so  that  they  will  withstand  the  launch  environment. 

The  torque  coil  on  the  top  side  makes  available  a  larger  area  of  0.1849  m"  for  use,  thus 
the  parameters  are  different  from  the  other  two.  Staying  with  the  32  gauge  wire  and 
keeping  in  mind  the  same  power  limitations  as  before  a  current  of  0.05A  will  be  in  use. 
This  provides  the  number  of  turns  as  325.  Giving  a  total  length  of  about  558  m  and  a 
power  rating  of  1.917  W. 

The  torque  coils  will  be  controlled  using  an  H  bridge,  which  allows  the  input  power  to  be 
reversed  based  on  a  control  voltage  placed  on  the  H  bridge.  The  torque  coils  will  need  to 
provide  a  dipole  in  both  directions  depending  on  the  momentum  vector  of  the  satellite 
and  reaction  wheels.  The  avionics  processor  can  switch  inputs  into  the  H  bridge  in  order 
to  switch  the  direction  of  the  current  flowing  through  the  coil,  and  therefore  switch  the 
dipole  provided.  The  avionics  processor  can  also  provide  a  pulse  width  modulated  signal 
to  the  H  bridge  so  that  the  current  flowing  through  the  coil  is  a  percentage  of  the 
maximum  current.  Therefore,  the  coils  can  be  powered  at  various  levels  depending  on 
the  amount  of  torque  they  need  to  provide. 

The  H  bridge  currently  being  used  as  a  pinout  diagram  shown  below.  This  H  bridge  is  a 
dual  model  and  can  be  used  to  operate  two  torque  coils.  The  entire  specifications  sheet 
for  this  device  can  be  found  at: 

http://search.digikev.com/scripts/DkSearch/dksus.dll?Detail&name=NJM2670D2%23- 

ND 
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FIGURE  2. 2. 3-4:  TORQUE  COIL  PINOUT 

The  torque  coils  will  also  have  a  current  sensor  providing  current  feedback  to  the 
processor.  The  current  sensor  is  not  intended  to  be  used  for  active  feedback  control  since 
high  precision  of  the  magnetic  dipole  is  not  necessary.  However,  a  current  feedback 
option  on  the  sensor  would  allow  the  avionics  processor  to  know  the  coil  is  on  and 
operational. 

9 

The  resistance  of  a  3  Am"  coil  with  the  dimensions  given  above  is  approximately 
366  Ohms.  The  maximum  power  required  by  each  coil  is  approximately  2  W.  When  in 
desaturation  mode,  all  three  coils  could  be  on  and  all  three  could  be  providing  3  Am2  of 
dipole.  In  this  worst  case  scenario,  the  coils  could  require  6  W  of  power.  However,  this 
case  is  unlikely.  On  average,  the  coils  will  be  on  for  approximately  15  minutes  per  orbit 
with  a  nominal  power  use  of  1 .5  W. 

REACTION  WHEEL  DATA 

The  reaction  wheel  model  used  on  the  satellite  will  be  the  Sinclair  Interplanetary  RW- 
0.060-28  model  which  provides  a  momentum  storage  capability  of  0.12  Nms  and  weighs 
0.225  kg  per  wheel.  The  specifications  for  the  Sinclair  Interplanetary  reaction  wheel  are 
given  below. 

Part  Name:  RW-0. 060-28 
Manufacturer:  Sinclair  Interplanetary 
Contact:  647-286-3761  voice,  775-860-5428fax 
HYPERLINK  dns  @  sinclairinterplanetary.com 
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Nominal  Momentum 

60  mNm-sec  @  6500  RPM 

Nominal  Torque 

>  5  mNm  @  28  V 

Control  Mode 

Speed  or  Torque,  built-in  control  CPU 

Command  /  Telemetry 

UART,  l2C/SMBus,  SPI,  RS-485,  CAN 

Mechanical 

75  mm  x  65  mm  x  38  mm,  225  g  mass 

Supply  Voltage 

7.5  V  to  35  V  nominal  (50  V  max) 

Supply  Power 

7.0  W  at  full  torque,  full  speed 

0.5  W  @  5000  RPM  steady-state 

0.2  W  @  2000  RPM  steady-state 

Environment 

-40°C  to  +70°C  operating  temperature 
>12  gRMS  Vibration,  >15  krad  total-dose 

Reliability 

Diamond  coated  hybrid  ball  bearings 

Redundant  motor  windings 

Heritage 

Flight  units  delivered  for  2  satellites. 

Fabrication  for  3  more  satellites  ongoing 

TABLE  2.2-6:  REACTION  WHEEL  CHARACTERISTICS 


CANCELLING  MAGNET 

ADCS  will  be  incorporating  a  cancelling  magnet  to  counteract  the  permanent  magnetic 
dipole  of  the  engine. 

•Neodymium  -  50%  stronger  magnetic  field  than  SmCo 
Theoretical  System  Dipole:  0.00552  Am2 


2.2.4  HARDWARE  OPERATIONS  DETAILS  (N.  CONDUAH) 

It  is  important  to  have  low  power  use  during  eclipse  because  the  battery  mass  required 
over  the  length  of  the  mission  has  to  increase  with  greater  required  power.  The  ACS  team 
has  developed  a  power  cycling  system  in  conjunction  with  the  power  team  such  that 
sufficient  knowledge  of  the  state  can  be  maintained  at  all  time  while  reducing  power 
consumption,  especially  during  eclipse. 

A  number  of  the  components,  such  as  the  IMU,  magnetometer,  and  GPS,  can  be  run  in 
faster  or  slower  modes.  We  expect  slow  changes  in  our  angular  rates,  and  the  GPS 
maximum  velocity  range  (8  km/s)  is  within  that  of  the  maximum  projected  velocity  of  the 
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satellite,  such  that  the  amount  of  information  provided  in  a  slow  mode  will  be  sufficient 
for  orbit  propagation  and  the  slower  settings  can  be  used  for  normal  operations.  During 
specific  events,  such  as  the  commissioning  phases  of  the  hardware,  it  would  be  useful  to 
have  the  higher  data  rates.  In  emergency  states  from  other  systems  that  result  in  low 
available  power,  the  components  have  sleep  or  standby  modes. 

For  our  reference  orbit  of  90  minutes,  the  sunlight  period  is  54  minutes,  and  the  eclipse 
period  is  36  minutes.  In  eclipse,  little  power  is  available  to  the  subsystem  to  maintain  the 
attitude  of  the  vehicle.  The  sun  sensor  is  not  available,  for  lack  of  sunlight.  The  largest 
power  draw,  the  GPS,  requires  up  to  10  minutes  to  turn  on  from  a  cold  start,  which  is 
prohibitive  when  the  eclipse  time/  sunlight  time  ratio  is  high.  A  warm  start  from  standby, 
on  the  other  hand,  takes  an  initialization  of  position  and  can  take  only  90  seconds  to  start. 
However,  if  the  GPS  fails  to  issue  data  within  10  minutes,  then  a  cold  start  reset  is 
completed. 

As  can  be  seen  in  the  figure  below,  to  avoid  the  need  for  a  cold  start,  the  GPS  will  be  put 
on  standby  at  the  start  of  eclipse  for  7  minutes,  then  give  it  a  warm  start  command  (90  s) 
and  operate  for  30  seconds,  long  enough  to  get  a  Position/Velocity/Time  solution.  This 
solution  will  be  stored  in  the  orbit  propagator  and  the  GPS  will  be  put  on  standby  again. 

A  36-minute  eclipse  period  gives  four  of  these  9-minute  cycles.  The  final  cycle  will  have 
a  standby  time  of  less  than  7  minutes  such  that  the  GPS  can  remain  on  for  more 
information  during  any  maneuvers  performed  while  exiting  eclipse.  The  precise  time  for 
this  maneuver  is  yet  to  be  determined,  but  will  be  less  than  5  minutes,  for  a  final  9-minute 
cycle  of  6  minutes  of  standby,  90  seconds  of  startup,  30  seconds  to  acquire  a  position, 
and  1.5  minutes  of  additional  information  gathering  before  eclipse  exit. 

The  magnetometer  and  IMU  will  remain  active  during  eclipse.  The  IMU  will  not  be  able 
to  be  re-initialized  fully,  as  the  magnetometer  reading  will  be  depending  on  a  position 
propagation  to  determine  attitude.  However,  the  drift  rate  of  4.2  °/Vhr  (where  the  V  refers 
to  a  root-mean-square  value)  is  small  enough  that  over  the  36  minute  eclipse,  the  unit  can 
be  relied  upon  to  give  control  inputs  if  necessary. 

The  reaction  wheels  operate  with  steady-state  power  of  0.2  W  each  at  2000  RPM  and  0.5 
W  at  5000  RPM.  The  reaction  wheels  are  capable  of  a  maximum  power  rating  of  7  W  at 
5000  RPM  when  maximum  torque  and  speed  are  called,  however  this  is  not  a  state  we 
desired,  since  power  will  be  kept  low  as  stated.  Since  the  orbit  buildup  of  non-cyclic 
torques  during  each  eclipse  cycle  is  small  and  this  momentum  will  need  to  be  dumped  at 
some  point,  the  team  has  chosen  to  desaturate  the  wheel  to  1000  RPM  using  torque  coils 
once  it  reaches  4000  RPM  steady-state.  This  allows  the  reaction  wheel  to  maintain  a  large 
amount  of  control  authority  but  keeps  the  required  power  during  eclipse  at  low  levels. 
Thus  the  reaction  wheels  will  be  on  during  eclipse  to  avoid  resultant  undesired  torques  on 
the  satellite  from  slowing  down. 
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FIGURE  2. 2. 4-1:  POWER  USE  IN  ECLIPSE 

The  power  team  is  currently  budgeting  power  tor  the  ACS  team  during  eclipse  tor  the 
cycling  of  the  GPS,  which  will  require  up  to  0.85W  when  on  and  a  non-zero  number  of 
Watts  during  standby  but  is  estimated  to  be  less  than  0.1  W,  as  well  as  0.2  W  of  constant 
power  to  the  reaction  wheel  (this  allows  a  time-averaged  margin  of  control  authority  for 
torquing  maneuvers  as  the  reaction  wheel  nears  a  steady-state  of  2000  RPM,  but  has  not 
yet  surpassed  it),  a  combined  0.1662  W  for  the  IMU  and  magnetometer  at  constant, 
normal- speed  operation. 

Total  W-hrs  budgeted  during  eclipse  is  3.28  W-hrs  before  efficiencies  are  factored  in, 
which  comes  to  4  W-hr  including  inefficiencies. 


TABLE  2. 2. 4-1:  POWER  USAGE  FOR  SENSORS  (SS  =  SUN  SENSOR,  MAG  = 

MAGNETOMETER) 


Sun/Eclipse,  State 

Components 

Power 

Sun,  Nominal  Power 

SS  (active)  +  IMU  (normal)  +  Mag  (nominal)  +  GPS 

1.0912  W 

Sun,  Min  Power 

SS  (idle)  +IMU  (fast)  +Mag  (sleep)  +GPS 

1.1612  W 

Eclipse,  w/GPS,  Nom  Power 

IMU  (normal)  +Mag  (nominal)  +GPS 

1.0162  W 

Eclipse,  w/GPS,  Min  Power 

IMU  (idle)  +Mag  (sleep)  +GPS 

0.8573  W 
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Eclipse,  w/o  GPS,  Nom  Power 

IMU  (normal)  +  Mag  (nominal) 

0.1662  W 

Eclipse,  w/o  GPS,  Min  Power 

IMU  (idle)  +  Mag  (sleep) 

0.0253  W 

TABLE  2. 2. 4-2:  POWER  USAGE,  ACTUATORS 


Component 

Power 

Reaction  Wheel 

0.2  W  @  2000RPM  (maintaining  wattage);  0.5  W  @  5000 
RPM(maintaining  wattage);  max  torque  @  7  W;  expected  average 
speed  of  5000  RPM  at  0.5  W  (maintaining  wattage) 

Torque  Coil 

2.0  W  @  3  AmA2;  max  dipole 

As  shown  in  Error!  Reference  source  not  found.,  the  data  rates  and  frequencies  for 
different  components  are  listed  below.  The  GPS,  being  utilized  on  the  normal  setting  (i.e 
quiet  not  verbose  mode)  provides  a  position,  velocity,  and  time  solution  every  10 
seconds.  Utilizing  an  orbit  propagation  program  within  software,  this  will  be  sufficient 
for  position  information  and  the  lower-power  setting  can  therefore  be  used. 


The  IMU  and  magnetometer  will  both  run  at  5  Hz  gain  sufficient  sampling  and  accuracy. 
Both  these  sensors  are  capable  of  sensing  beyond  100  Hz  for  additional  accuracy; 
however,  running  them  slightly  slower  reduces  the  data  and  processing  loads.  The  sun 
sensor  is  run  at  5  Hz  as  a  default. 

The  reaction  wheels  are  run  at  1  Hz  and  the  torque  coils  require  pulse  with  modulation  at 
a  rate  sufficiently  lower  than  the  number  of  dipole  divisions.  The  avionics  processor 
provides  capability  of  216  levels  of  fidelity  in  width  size.  As  such  it  is  possible  for  ADCS 
to  continuously  command  dipole  levels  between  -3  and  3  Am". 


TABLE  2. 2. 4-3:  DATA  RATES  AND  FREQUENCIES 


Component 

Data  Rate 

Command  or 

Sensing  Rate 

GPS 

19.2  kbps 

0.1  Hz 

IMU 

8.4  kbps 

100  Hz 

Magnetometer 

2.4  kbps 

100  Hz 

Sun  Sensor 

57.6  kbps 

5  Hz 
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Reaction  Wheels 

57.6  kbps 

1  Hz 

Torque  Coils 

1  kbps 

100  Hz 

2.2.5  ATTITUDE  CONTOL  LAW  (C.  DEVIVERO) 

A  fully  parametric  simulation  of  the  three  dimensional  attitude  and  position  dynamics  of 
the  vehicle  has  been  developed  and  is  in  the  process  of  final  debugging.  This  simulation 
is  intended  for  use  as  an  assessment  tool  for  developing  attitude  control  algorithms  for  the 
CASTOR  satellite  in  a  simulation  environment  which  accurately  represents  the 
environment  of  space,  including  all  sources  of  external  torque  and  force. 

CONTROLLER  DESIGN 

This  section  details  the  control  algorithms  which  will  be  implemented  in  three 
dimensions,  including  descriptions  of  how  they  are  reduced  to  two  dimensional  problems 
and  how  the  two  dimensional  control  laws  are  extended  back  to  three  dimensions.  For 
most  aspects  of  attitude  control,  desired  torques  will  be  computed,  and  mixing  functions 
used  to  set  actuator  states  to  produce  approximately  the  desired  torque.  These  mixing 
functions  are  not  discussed  in  detail  here. 

The  overall  design  of  the  attitude  control  algorithms  is  driven  by  a  desire  for  control  law 
robustness  to  variation  in  the  physical  parameters  of  the  system  and  the  external 
environment,  as  well  as  efficient  performance,  and  the  ability  to  point  the  solar  arrays 
toward  the  sun  using  only  the  minimum  attitude  information  required  to  do  so. 

For  the  purposes  of  the  following  discussion,  a  diagram  indicating  some  of  the  geometric 
CASTOR  parameters  and  the  definition  of  the  body  frame  axes  used  by  the  simulation  is 
included  in  Figure  2.2.5- 1:  CASTOR  BODY  FRAME  AXIS. 
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FIGURE  2. 2. 5-1 :  CASTOR  BODY  FRAME  AXIS 

SIMULATION  RESULTS 

Determining  the  value  of  the  engine’s  magnetic  dipole  moment  is  required  in  order  to 
accurately  model  the  effects  of  the  space  environment  on  the  satellite.  Readings  of  the 
local  magnetic  field  have  been  taken  for  several  positions  with  respect  to  the  engine  in 
the  off  state,  and  the  results  indicate  a  relatively  strong  effect  on  the  magnetic  field 
measured  by  the  engine. 


TABLE  2. 2. 5-1:  NON-THRUSTING  MAGNETIC  FIELD 


Location  Relative  to  Engine 


Magnetic  Field  Reading  (x  y  z)*  (Gauss) 
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0.6m  x,  along  thrust  axis 

-0.191997 

-1.150754 

37.8 

0.4m  x,  along  thrust  axis 

-0.247530 

-0.335008 

37.3 

0.2m  x,  along  thrust  axis 

-0.716794 

-0.224456 

39.2 

0.1m  x,  along  thrust  axis 

-10.394747 

-0.572864 

36.3 

0.4m  x,  0.1m  toward  cathode 

0.042921 

-0.144054 

38.5 

0.4m  x,  0.1m  away  from  cathode 

-0.382171 

-0.495812 

35.8 

The  following  steps  were  taken  to  determine  the  dipole  moment  of  the  engine  in  the  off 
state: 

1.  Calibrate  magnetometer  and  place  it  in  a  fixed  location  far  (over  2  m)  from  the 
main  engine. 

2.  Record  several  magnetometer  readings,  and  average  them  to  determine  the 
baseline  magnetic  field  direction. 

3.  Place  the  main  engine  at  various  locations  relative  to  the  magnetometer,  recording 
magnetic  field  readings  for  each  location. 

4.  Using  the  corrected  value  of  the  magnetic  field  readings  at  various  locations 
relative  to  the  engine,  apply  a  regression  using  the  point  dipole  equation  to 
estimate  the  dipole  moment  of  the  engine. 

After  performing  the  test  described  above,  the  main  engine  dipole  is  determined  to  be 
approximately  20.4  A-m“.  Tests  must  be  performed  for  the  engine  in  the  on  state,  and  the 
estimated  values  of  the  engine  magnetic  dipole  moment  incorporated  into  the  parametric 
simulation,  and  accounted  for  in  the  design  of  control  and  estimation  algorithms. 

An  initial  simulation  has  been  performed,  and  its  results  shown  in  Figure  2.2-2  and 
Figure  2.2-3.  This  simulation  models  the  three  dimensional  attitude  dynamics  of  the 
satellite  with  environmental  disturbances  and  plots  the  external  torques  and  forces  on  the 
vehicle  as  a  function  of  time  as  it  progresses  through  several  circular  orbits  at  four 
hundred  kilometers  of  altitude  and  twenty  six  degrees  of  inclination,  with  fixed  attitude 
and  reference  tracking  attitude  respectively.  The  decomposition  of  net  torques  by  source 
indicates  that  the  external  torque  on  the  vehicle  is  dominated  by  magnetic  dipole-dipole 
interaction,  and  the  net  external  force  is  dominated  by  aerodynamic  drag.  Due  to  the  large 
magnetic  dipole  of  the  engine  and  its  strong  interaction  with  the  earth’s  magnetic  field,  a 
permanent  magnet  will  be  placed  on  the  satellite  to  counteract  the  magnetic  dipole  of  the 
main  engine. 
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FIGURE  2.2-2:  NET  EXTERNAL  DISTURBANCES  (FIXED  ATTITUDE) 


The  physics  implemented  to  simulate  various  aspects  of  the  space  environment  are  not 
detailed  in  this  document.  However,  the  parameters  from  which  this  simulation  was  based 
on  have  since  changed.  Most  importantly,  the  planned  orbital  altitude  is  550km,  with  an 
inclination  of  45  degrees.  A  new  simulation  is  currently  under  development,  and  will  take 
into  account  the  addition  of  the  cancelling  magnet  to  reduce  the  effect  of  earth’s  magnetic 
field  on  the  dynamics  of  the  satellite.  The  new  simulation  will  also  demonstrate  the 
performance  of  the  current  ACS  design,  i.e.  its  ability  to  control  the  satellite  attitude  to 
meet  mission  requirements. 
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ATTITUDE  CONTROL  ALGORITHMS 


Lor  the  purposes  of  the  control  algorithm  that  will  operate  the  satellite,  the  state  of  the 
satellite  shall  be  defined  in  terms  of  its  position  and  attitude: 


This  state  includes  the  full  position  and  velocity  of  the  CASTOR,  its  attitude  as  described 
by  three  Euler  angles,  and  its  rotational  rates. 

A  state  space  model  defined  by, 


—  —  Ax  +  Bu 

dt 


(1) 


y  —  Cx  +  Du 


(2) 


can  be  used  to  linearize  the  dynamics  of  the  satellite  and  the  sensor/actuator  suite  for 
CASTOR.  This  state  space  model  will  be  used  in  simulations  as  an  aid  to  designing  the 
control  law  algorithm,  and  will  also  be  used  for  orbit  propagation  to  estimate  satellite 
position  and  attitude  during  operations.  Attitude  control  will  be  performed  primarily  by 
the  reaction  wheels.  Torque  coils  will  be  used  for  detumbling,  rate  damping,  and 
desaturation  of  the  reaction  wheels  if  they  exceed  acceptable  rate  limits. 

Over  the  course  of  each  orbit,  the  attitude  control  requirements  will  change,  and  the 
reference  attitude  to  be  tracked  by  the  satellite  will  be  determined  in  various  ways. 
Additionally,  sensor  suite  capability  will  be  reduced  during  eclipse  because  the  sun 
sensors  cannot  be  used.  This  gives  rise  to  three  distinct  modes  of  operation  and  two 
different  means  of  determining  reference  attitude. 

Mode  1  -  Lull  attitude  control  mode 

This  mode  provides  full  attitude  tracking  for  any  reference  attitude,  and  is  suitable  for  all 
situations  in  which  full  attitude  control  is  required,  including  periods  of  engine  firing  and 
battery  recharge.  Sensor  input  shall  be  taken  from  the  magnetometer,  sun  sensor,  IMU, 
and  GPS.  The  reaction  wheels  shall  be  used  to  actuate  the  satellite.  The  reference  attitude 
is  derived  from  one  of  the  following  two  conditions: 

1 .  Pointing  of  the  engine  along  the  velocity  vector,  to  maximize  thruster  efficiency. 

2.  Pointing  of  the  solar  panels  towards  the  sun  to  maximize  solar  array  power  output 
during  the  battery  recharge  phase. 

Mode  2  -  Eclipse  mode 

This  mode  disables  attitude  control  (i.e.  the  reaction  wheels),  and  shall  receive  sensor 
input  from  the  magnetometer,  IMU,  and  GPS.  During  this  mode,  accurate  attitude 
tracking  is  not  essential,  and  disabling  control  of  the  reaction  wheels  conserves  power. 
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Mode  3  -  Desaturation  mode 

This  mode  is  similar  to  Mode  1,  as  it  will  provide  for  full  attitude  tracking,  but  will  use 
the  torque  coils  to  exert  an  external  torque  on  the  satellite,  with  the  purpose  of 
desaturating  the  reaction  wheels.  Sensor  input  shall  be  taken  from  the  sun  sensor,  IMU, 
and  GPS.  Note  that  the  magnetometer  cannot  be  used  since  the  torque  coils  will  skew  the 
measurement  readings. 

For  full  attitude  tracking,  the  control  law  can  be  formulated  as  follows: 

Defining, 

Three  coordinate  systems:  E  -  Fixed  to  the  earth.  B  -  Fixed  to  the  body  of  the  satellite.  R 
-  Fixed  to  the  body  of  the  reference  attitude. 

Teb  Ter  Tbr  Matrix  transformations  from  E  to  B,  E  to  R  and  B  to  R  respectively. 

vE  vB  vR  Representation  of  a  vector  in  each  coordinate  system. 

s  m  Unit  vectors  pointing  from  the  satellite  to  the  sun,  and  in  the  direction  of 

the  local  magnetic  field  respectively. 

The  sensor  suite  acquires  a  magnetic  field  vector  in  B,  and  the  magnetic  field  vector  in  E 
can  be  determined  according  to  the  satellite’s  orbital  position  (acquired  from  the  GPS). 
Applying  matrix  transformations  to  these  two  vectors,  the  coordinate  system  B  relative  to 
E  can  be  determined,  yielding  the  satellite’s  attitude  relative  to  E.  The  same  process  can 
be  applied  to  the  sun  vector  acquired  from  the  sun  sensor  ( sB ),  and  the  known  sun  vector 
in  E  (se)  as  inferred  by  the  orbital  position  of  the  satellite,  in  order  to  derive  the  satellite’s 
attitude  as  well.  The  two  attitude  determinations  are  passed  through  an  Extended  Kalman 
Filter  to  arrive  at  a  single  attitude  determination.  The  control  law  then  takes  as  input  the 
satellite’s  attitude  and  the  reference  attitude  to  yield  rotations  necessary  to  bring  the 
satellite’s  attitude  to  the  reference  attitude. 

Dynamic  output  feedback  control  will  be  used  to  command  angular  acceleration,  and 
knowledge  of  the  vehicle’s  moment  of  inertia  will  be  used  to  mix  these  commands  to  a 
three  dimensional  torque  to  be  applied  by  the  reaction  wheels.  Assuming  a  simple  model 
of  the  satellite  dynamics  given  by, 


£t  =  Id 


(3) 


where  the  sum  of  torques  is  given  by  the  torque  produced  by  the  reaction  wheel,  tr. 


£  T  —  tr  —  ~Ir^r 


(4) 


a  state-space  model  can  be  formed  following  equations  1  and  2: 


a.  —  ii  R 
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e 

.6. 


+ 


J_R 
/  . 


fir. 


0  =  [1  0][^]  +  [0]4 


Using  a  Dynamic  Output  Feedback  controller  yields  the  following  closed-loop  dynamics: 


'  A 
BcC 


°d 


(5) 

(6) 


where  xc  is  the  estimated  state;  Ac,  Bc,  and  Cc  correspond  to  the  compensator’s  dynamics; 
r  is  the  reference  state,  and  becomes  the  new  input  to  the  system;  N  is  a  scaling  factor 
applied  to  the  reference  input. 


Ac=  A-BK-  LC,  Bc  —  L,  Cc  —  K,  N  — 


-BCc 

Ac 


-l 


-l 


There  are  two  degrees  of  freedom  with  this  compensator,  which  are  the  regulator  gain,  K, 
and  the  estimator  gain,  L.  The  regulator  gain  can  be  found  by  implementing  a  Linear 
Quadratic  Regulator  which  optimizes  the  choice  of  K,  given  a  more  understandable  set  of 
specifications.  The  gain  K  is  found  by  minimizing  the  equation: 


J  —  f™[xTQx  +  uTRu]dt 


(7) 


The  details  of  optimizing  this  equation  are  not  represented,  since  there  is  a  Matlab 
function  that  produces  the  gain  K,  given  the  plant  dynamics,  Q,  and  R.  The  matrices  Q 
and  R  are  chosen  according  to  a  set  of  rules  of  thumb: 


<2  = 


a2 

vmax 


o 


a2 


h2 

°max. 


R  —  P' 


i 


2 

max 


where  9max  and  9max  are  the  maximum  desired  output  of  these  signals,  aq  and  a2  are 
relative  weights  assigned  to  each  signal,  flmax  is  the  maximum  desired  input  of  this 
signal,  and  p  is  a  relative  weight  between  input  and  output.  The  sum  of  a(  and  a|  must 
equal  1 .  The  LQR  then  produces  a  set  of  regulator  poles  in  the  final  closed-loop  system. 


The  estimator  gain  L  is  selected  based  on  the  rule  of  thumb  of  making  the  estimator  poles 
about  twice  as  fast  as  the  regulator  poles,  i.e.  the  real  component  of  the  estimator  poles  is 
twice  that  of  the  regulator  poles.  The  details  of  deriving  L  are  not  presented,  since  there  is 
a  Matlab  function  that  produces  the  gain  L,  given  the  plant  dynamics  and  the  desired 
estimator  pole  locations. 
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The  closed-loop  dynamics  given  by  equations  5  and  6  yield  the  control  law  equation: 


u  =  —Ccxc  -I-  Nr 

Using  the  procedure  outlined  above,  equation  8  becomes: 


n  =  -K 


est 


\e 

L@estJ 


+  NO 


ref 


(8) 


(9) 


FIGURE  4:  REACTION  WHEEL  CONTROL  LAW 

Figure  4  shows  a  block  diagram  of  the  control  algorithm  used  to  actuate  the  reaction 
wheels,  as  given  by  equation  9.  The  control  law  is  applied  to  each  of  the  three  reaction 
wheels,  in  terms  of  the  Euler  angle  that  corresponds  to  the  reaction  wheel.  The  reference 
angle,  9ref,  may  be  determined  by  the  sun  sensor,  or  the  estimated  velocity  vector.  The 
estimated  angle,  0est,  is  determined  by  the  sensor  suite.  The  angular  rate,  co  (equivalent  to 
9  in  eq.  9),  is  determined  by  the  IMU,  and  the  resulting  torque  command,  tr,  is  sent  to  the 
reaction  wheels.  The  gains  kp  and  k,j  correspond  to  the  elements  of  matrix  K:  K  — 

[kp  kd\ .  The  gain  N  is  a  scaling  factor  applied  to  the  reference  input,  as  described 
previously. 

Applying  this  control  torque  will  cause  the  vehicle  to  stably  converge  to  the  reference 
attitude  using  the  shortest  angle  of  rotation  possible.  If  the  inertia  matrix  is  not  a  multiple 
of  the  identity  matrix  however,  this  will  be  a  sub-optimal  path  in  terms  of  energy  use. 

ATTITUDE  CONTROL  SOFTWARE 

The  general  structure  of  the  software  will  consist  of  an  Extended  Kalman  Filter  for 
estimation,  acquiring  full  attitude  measurements  with  a  relatively  low  frequency  (5Hz), 
execute  control  law  functions  which  run  at  a  yet  lower  frequency  (1Hz),  and  compute  the 
required  control  torques  which  serve  as  the  input  to  mixing  functions.  The  mixing 
functions  will  translate  these  higher  level  control  commands  into  specific  actuation 
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commands  for  the  various  actuators.  Auxiliary  matrix  math,  vector  math,  and  mixing 
functions  will  be  called  whenever  required  by  the  core  estimation  and  actuation  threads. 

A  full  description  of  these  auxiliary  libraries  and  mixing  functions  is  TBR. 

Table  2-2  describes  the  ACS  Application  Programming  Interface  (API),  a  preliminary  list 
of  basic  avionics  software  functions  that  must  be  implemented  in  order  to  interface  with 
the  ACS  hardware  components. 


TABLE  2-2:  ACS  API 


Component 

Function 

Signal 

Direction 

(w.r.t. 

Avionics) 

Return 

Type 

Units 

Description 

IMU 

Get_Acc_V  ector() 

Input 

float* 

meters/second2 

Returns  a  pointer  to  an 
array  of  3  floats,  where  the 
first  element  is  the  x- 
component  of  acceleration, 
second  element  is  y- 
component,  and  third 
element  is  the  z- 
component. 

Get_Rate_V  ectorQ 

Input 

float* 

radians/second 

Returns  a  pointer  to  an 
array  of  3  floats,  where  the 
first  element  is  the  angular 
velocity  about  the  x-axis, 
second  element  about  the 
y-axis,  and  third  element 
about  the  z-axis. 

Magnetometer 

Get_Mag_V  ector() 

Input 

float* 

microtesla 

Returns  a  pointer  to  an 
array  of  3  floats,  where  the 
first  element  is  the  x- 
component  of  the  magnetic 
field,  second  element  is  y- 
component,  and  third 
element  is  the  z- 
component. 

Sun  Sensor 

Get_Sun_V  ector( 
int  id,  int*  fit,  int* 

Input 

float* 

N/A 

Takes  as  input  one  integer 
and  two  integer  pointers, 
where  id  is  the  sun  sensor 
to  query  (0,  1,  2,  or  3).  The 
function  sets  the  value  of 
fit  to  the  queried  sun 
sensor's  Fit  Quality,  and 
geometry  to  the  sun 
sensor's  Geometry  Quality. 

geometry) 

Returns  a  pointer  to  an 
array  of  3  floats,  where  the 
first  element  is  the  x- 
component  of  the  vector  to 
the  sun,  second  element  is 
y-component,  and  third 
element  is  the  z- 
component. 
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GPS 

Get_Position_V  ector() 

Input 

float* 

meters 

Returns  a  pointer  to  an 
array  of  3  floats,  where  the 
first  element  is  the  x- 
component  of  the  position 
(in  WGS-84  XYZ 

Cartesian  coordinates), 
second  element  is  y- 
component,  and  third 
element  is  the  z- 
component. 

Get_V  elocityJV  ec  tor() 

Input 

float* 

meters/second 

Returns  a  pointer  to  an 
array  of  3  floats,  where  the 
first  element  is  the  x- 
component  of  the  velocity 
(in  WGS-84  XYZ 

Cartesian  coordinates), 
second  element  is  y- 
component,  and  third 
element  is  the  z- 
component. 

Reaction 

Wheel 

Get_Wheel_Torque( 
int  id) 

Input 

float 

Newton- 

meters 

Takes  as  input  one  integer, 
where  id  is  the  reaction 
wheel  to  query  (0,  1,  or  2). 
The  function  returns  the 
amount  of  torque  being 
generated  by  the  queried 
wheel. 

Get_Wheel_Speed( 
int  id) 

Input 

float 

radians/second 

Takes  as  input  one  integer, 
where  id  is  the  reaction 
wheel  to  query  (0,  1,  or  2). 
The  function  returns  the 
angular  velocity  of  the 
queried  wheel. 

Set_Wheel_Torque( 
int  id,  float  torque) 

Output 

void 

Newton- 

meters 

Takes  as  input  one  integer 
and  one  floating  point 
value,  where  id  is  the 
reaction  wheel  to 
command  (0,  1,  or  2),  and 
torque  is  the  amount  of 
torque  the  specified 
reaction  wheel  should  be 
commanded  to  generate. 

Torque  Coil 

Set_Coil_Torque( 
int  id,  float  torque) 

Output 

void 

Newton- 

meters 

Takes  as  input  one  integer 
and  one  floating  point 
value,  where  id  is  the 
torque  coil  to  command  (0, 

1,  or  2),  and  torque  is  the 
amount  of  torque  the 
specified  coil  should  be 
commanded  to  generate. 

The  continuous-time  control  law  given  by  equation  9  can  be  discretized  to  be 
implemented  on  a  micro-controller.  Equation  9  can  be  expanded  to: 
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H  -  —kp9  —  kd9  +  N6ref 


The  commanded  acceleration  is  substituted  with  a  discrete -time  equivalent, 


n  = 


^i+ 1 
A ti 


(10) 


where  Oi+i  is  the  speed  of  the  reaction  wheel  to  be  commanded  in  the  current  time-step, 

Oj  is  the  current  speed  of  the  reaction  wheel,  and  Atj  is  the  difference  in  time  between  the 
last  time-step  and  the  current  time-step.  The  gains  kp,  kd,  and  N  are  given  by  the  control 
law  algorithm,  0  is  the  best  estimate  of  the  satellite’s  attitude,  9  is  the  angular  rate  given 
by  the  IMU,  and  9ref  is  the  desired  attitude  reference  angle.  Equation  11  is  the  resulting 
equation  that  can  be  implemented  on  the  micro-controller. 

fli+1  —  {—kp9  —  kd9  +  N9ref)/S.ti  +  fit  (11) 


2.3  AVIONICS 


2.3.1  REQUIREMENTS  (L.  DE  LA  GARZA) 


The  avionics  system  is  the  primary  interface  between:  ADCS,  Thermal,  Power, 
Propulsion,  Structures,  Communications,  and  Operations.  The  avionics  subsystem  is 
composed  of  two  primary  aspects:  hardware  and  software.  The  hardware  provides  the 
physical  connections  and  logic  circuits  necessary  for  connecting  to  sensors  and  actuating 
devices.  The  software  provides  the  logic  for  ensuring  that  the  sensor  data  is  acted  upon 
properly.  The  requirements  for  the  avionics  subsystem  are: 

•  Provide  all  necessary  interfaces  between  subsystems 

•  Accommodate  all  required  onboard  data  processing 

The  full  design  requirements  can  be  found  in  5.1  below. 

Avionics  and  Software  shall: 

1 .  Provide  the  necessary  data  interfaces  to  support  all  subsystems 

■  Poll  sensor  data  at  a  frequency  of  at  least  4  Hz 

•  Run  the  propulsion  system's  engine  firing  logic  twice  per  orbit  as  well  as 
continually  monitor  the  propulsion  system 

•  Integrate  with  ACS  subsystem  to  execute  estimation  and  control 

■  Kalman  Filter 

•  Periodic  control  law 

•  GPS  data 
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•  SPG4  propagator 

•  Interface  with  the  communications  subsystem  to  send  and  receive  data. 

•  Provide  the  interface  for  power  subsystem 

•  Interface  with  the  imaging  subsystem 

•  One  image  per  orbit  without  overriding  the  data  for  2  weeks 

•  Provide  the  computing  power  and  data  storage  capacity  necessary 
Be  fault  tolerant  and  able  to  recover  from  SEU  failure 

•  Detect  SEU  faults  by  checksums  of  the  memory  and  storage 

•  Recover  from  an  SEU  fault  <1  minute  from  the  time  of  detection 

2.  Retain  programming  and  state  when  unpowered 

3.  Permit  software  updates 


2.3.2  OVERVIEW  (S.  GOMEZ) 


The  avionics  hardware  consists  of  three  dsPIC33F  microcontrollers  mounted  on  a  custom 
avionics  board  and  a  1GB  NAND  Flash  module.  These  dsPICs  provide  the  computational 
power  necessary  for  all  operations  to  occur  during  flight  as  shown  in  the  Computing 
Budget  in  Section  2.3.3  .  The  usage  of  three  microcontrollers  adds  a  level  of  robustness 
and  redundancy  to  the  overall  avionics  system.  The  three  microcontrollers  have  the 
ability  to  reprogram  one  another  in  flight  to  recover  from  operational  hazards  such  as 
Single  Event  Upsets  (SEUs).  In  addition  to  the  ability  to  reprogram  the  satellites  the  PIC 
shall  be  responsible  ensuring  the  proper  resources  are  allocated  across  all  the  PICs  to 
ensure  that  no  single  PIC  failure  will  cause  the  entire  system  to  stop  functioning. 

The  most  computationally  intense  portion  of  the  flight  operations  will  be  the  Attitude 
Determination  and  Control  System’s  (ACDS)  state  estimation  and  control  algorithms. 
Previous  tests  have  shown  that  a  single  dsPIC  is  more  than  capable  of  running  the 
Kalman  Filter  code  at  the  required  accuracy.  The  third  microcontroller  will,  almost 
exclusively,  handle  the  ADCS’s  Kalman  Filter  for  attitude  estimation  and  control 
propagator.  The  first  two  dsPICs  will  handle  more  general  flight  operations.  PICs  one  and 
two  shall  run  identical  software  and  will  handle  sensor  reading,  communications,  and 
engine  operations.  In  the  event  of  a  failure  in  PIC  3  the  remaining  two  PICs  will  be  able 
to  run  a  reduced  accuracy  version  of  the  control  system. 

The  avionics  system  will  also  be  responsible  for  the  handling  of  all  data  onboard  the 
satellite.  The  avionics  board  provides  the  hardware  interface  between  the 
microprocessors,  the  NAND  flash,  and  the  various  sensors  aboard.  The  dsPICs  will 
process  all  of  the  data  coming  in  from  these  sensors  and  transmit  or  store  the  data  on  the 
flash  module  when  necessary.  The  data  stored  in  the  flash  memory  will  later  be 
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accessible  to  the  Communications  subsystem  for  downlink  to  the  ground.  The  overall 
hardware  architecture  of  the  avionics  hardware  system  is  present  in  Figure  2.3-1. 
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FIGURE  2.3-1:  AVIONICS  HARDWARE  SCHEMATIC 

The  Avionics  software  system  requires  a  hard  real  time  operating  system  (RTOS)  to 
manage  system  operations  and  schedule  required  tasks  in  order  to  meet  operational 
deadlines.  Avionics  will  be  deploying  the  ThreadX  RTOS  to  handle  scheduling  of  the 
multiple  threads  necessary  for  CASTOR  to  operate.  Individual  threads  will  be  responsible 
for  different  tasks  that  are  required  to  run  concurrently.  The  RTOS  will  schedule  these 
threads  to  run  periodically  with  deadline  constraints  while  handling  hardware  interrupts. 
The  general  software  task  are  listed  below. 


Operations  Task 

Task:  provides  overarching  logic  and  control  of  system 

—Regular  Operations 

Thread:  basic  structure  of  tasks  and  priorities  for  normal  operations 

—Commissioning 

Thread:  basic  structure  for  how  the  satellite  will  begin  life 

16.83  CASTOR  Design  Document 


Page  89 


November  18,  2010 


Control  Task 

Task:  runs  attitude  control  law 

Propagator 

Task:  estimates  current  orbital  position  and  attitude 

—Attitude 

Thread:  estimates  the  satellite’s  current  attitude 

—Position 

Thread:  estimates  the  satellite’s  current  position 

Power  Management 

Task:  manages  the  distribution  of  power  throughout  the  system 

Communications 

Task 

Task:  manages  communication  between  the  satellite  and  the  ground 
station 

Sensor  Recording 

Task:  records  sensor  data 

Imaging  Task 

Task:  takes  pictures  of  the  thruster’s  plume 

Operate  Actuators 

Interrupt:  operates  control  actuators 

-SPRM 

Thread:  logic  for  solar  panel  release  mechanism 

—Torque  Coil 

Thread:  logic  for  operating  torque  coils 

—Reaction  Wheel 

Thread:  logic  for  operating  the  reaction  wheels 

Threshold  Interrupt 

Interrupt:  ensures  sensor  measurements  are  not  over  threshold  values 

Sensor  Measurement 

Interrupt:  reads  sensor  values 

—Thermal  Sensors 

Thread:  logic  for  reading  thermal  couples  and  thermal  sensors 

—Power  Sensors 

Thread:  logic  for  reading  voltage  and  current  sensors 

-GPS 

Thread:  logic  for  reading  GPS  unit 

-IMU 

Thread:  logic  for  reading  IMU  gyros 

—Magnetometer 

Thread:  logic  for  reading  magnetometer  values 

—Sun  Sensor 

Thread:  logic  for  reading  sun  sensor  data 

TX  Data 

Interrupt:  processes  incoming  data 

RX  Data 

Interrupt:  packetizes  and  sends  data  to  ground  station 

TABLE  2.3-1:  TASK  BREAKDOWN 


Additionally,  the  Avionics  software  system  will  provide  a  common  software  interface  for 
other  subsystems  to  communicate  effectively  with  their  hardware  components.  Avionics 
has  defined  an  API  for  accessing  various  sensor  data. 


2.3.3  COMPUTING  BUDGET  (S.  GOMEZ) 
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Establishing  an  accurate  model  of  the  utilization  of  avionics  resources  is  a  crucial  part  of 
ensuring  that  the  avionics  hardware  can  handle  all  of  the  necessary  operations  for 
CASTOR’S  flight.  An  in-depth  analysis  has  been  performed  to  estimate,  and  where 
possible  measure,  CPU,  Memory,  and  Bus  utilization  under  different  operational 
conditions.  The  system  has  been  designed  so  that  avionics  resources  are  capable  of 
handling  the  worst  case  scenario  events. 


Start  Up  and  Self  Test 


The  Start  Up  and  Self  Test  scenarios  will  not  be  commonly  reoccurring  scenarios  during 
CASTOR’S  flight.  Regardless,  these  scenarios  must  be  accounted  for  and  shown  to  be 
within  the  realm  of  feasibility  for  the  designed  flight  hardware. 
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FIGURE  2.3-2:  CPU  UTILIZATION 
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FIGURE  2.3-3:  BUS  UTILIZATION 
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FIGURE  2.3-4:  MEMORY  UTILIZATION 

The  figures  above  show  that  the  avionics  hardware  can  easily  handle  the  computational 
and  data  load  put  forward  during  satellite  start-up  and  self-test.  The  CPU  utilization  peaks 
at  34%  on  PIC  2,  Bus  Utilization  peak  at  only  10%  on  UART  1  for  PICs  1  and  2,  and 
data  storage  is  minimal.  Less  than  0.016%  of  memory  at  start-up  and  several  orders  of 
magnitude  lower  during  a  satellite  self-test  (not  visible  in  Figure  2.3-4). 


16.83  CASTOR  Design  Document 


Page  92 


November  18,  2010 


Regular  Operations  (Sun  and  Eclipse) 


The  regular  operations  states  will  be  the  most  common  states  for  CASTOR  to  remain  in. 
There  are  two  phases  of  regular  operation.  In  the  Sun  phase  CASTOR  is  in  orbital  day, 
the  satellite  is  able  to  use  its  deployed  solar  panels  to  provide  power  across  the  satellite 
and  store  energy  in  CASTOR’s  batteries.  In  contrast  the  Eclipse  operations  will  take 
place  during  orbital  night.  The  power  available  is  only  what  was  stored  in  the  batteries 
during  previous  orbital  days.  This  places  a  much  tighter  constraint  on  the  power  that  can 
be  utilized  by  the  satellite.  This  puts  less  of  a  constraint  on  CPU,  Bus,  and  Memory 
Utilization  because  all  operations  are  power  limited. 
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FIGURE  2.3-5:  CPU  UTILIZATION  REGULAR  OPERATIONS 
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FIGURE  2.3-6:  BUS  UTILIZATION  REGULAR  OPERATIONS 
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FIGURE  2.3-7:  MEMORY  UTILIZATION  REGULAR  OPERATIONS 

Under  normal  operations  all  resources  necessary  by  the  satellite  are  available  during  all 
planned  operational  procedures  during  flight.  Memory  usage  is  minimal  in  all  cases  and 
Bus  utilization  is  well  within  bounds.  CPU  usage  during  orbital  day  increases  to  an 
estimated  93%,  still  within  the  capabilities  of  the  system,  however  the  margin  for  error 
might  be  too  small. 

Worst  Case  Operations 

A  worst  case  scenario  computing  budget  has  be  created  to  ensure  that  CASTOR  will  have 
the  resources  available  to  endure  any  event  possible  during  flight.  The  worst  case 
scenario  occurs  when  one  PIC  undergoes  an  SEU  and  must  be  reprogrammed  by  the 
remaining  PICs  while  those  PICs  are  still  undergoing  normal  operations.  Estimates  for 
resource  utilization  are  given  in  the  figures  below.  The  load  on  each  PIC  is  calculated 
with  the  assumption  that  one  other  PIC  has  failed  in  some  way.  All  three  PICs  would  not 
have  these  loads  at  the  same  time  even  in  this  worst  case  scenario. 
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CPU  Utilization  Worst  Case 
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FIGURE  2.3-8:  CPU  UTILIZATION  WORST  CASE 


Bus  Utilization  Worst  Case 


P 

$ 


UARTl 


UART2 


I2C 


SPI  1 


SPI  2 


CAN 


PIC1  ■  PIC  2  ■  PIC  3 


FIGURE  2.3-9:  BUS  UTILIZATION  WORST  CASE 
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FIGURE  2.3-10:  MEMORY  UTILIZATION  WORST  CASE 


In  the  worst  case  scenario  CPU  utilization  is  near  100%  in  PIC  3  and  the  UART  1  Buses 
are  completely  saturated  on  PICs  1  and  2.  However,  all  the  loads  put  on  the  avionics 
resources  are  within  the  range  of  feasibility  for  the  system.  The  saturation  of  the  UART 
buses  represents  communications  using  the  full  capabilities  of  the  data  bus,  and  does  not 
imply  a  lack  of  resources.  The  CPU  utilization  on  PIC  3  is  estimated  at  98%  during  this 
worst  case  scenario,  leaving  little  margin  for  error.  However,  this  could  be  reduced  by 
performing  imaging  tasks  at  a  lower  frequency  or  moving  some  responsibilities  to  the 
other  functioning  PIC  until  the  final  PIC  is  back  up  and  running. 


2.3.4  RISKS  &  MITIGATION  STRATEGIES  (J.  NASH) 


The  following  list  enumerates  the  various  risks  the  avionics  system  shall  be  designed  to 
mitigate,  along  with  the  mitigation  strategies  that  are  being  followed  by  the  CASTOR 
avionics  team.  A  summary  of  the  information  is  found  in  Table  2.3-2. 

•  PIC  hardware  failure 

o  If  the  PIC  fails  to  respond  with  a  given  timeout  interval,  it  will  be 
considered  failed 

o  Radiation  hardened  components  were  not  chosen  due  to  their  cost,  so 
space  and  solar  radiation  is  a  potential  cause  of  failure  in  Low  Earth  Orbit 
(LEO) 

o  Mitigation  strategies: 

■  Perform  the  following  steps  in  order  until  successful  recovery 
1.  Hardware  watchdog  reset 
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2.  CAN  bus  watchdog  reset  by  other  PIC 

3.  Reprogramming  (ICSP) 

4.  Disabling  (reprogram  other  PICs  to  fulfill  functions) 
o  Severity:  4.  If  one  PIC  fails,  the  mission  will  be  delayed,  but  due  to 

hardware  redundancy,  the  failure  of  one  PIC  does  not  jeopardize  the 
ability  to  complete  the  mission 

o  Likelihood:  1.  In  LEO,  the  avionics  system  will  not  be  heavily  bombarded 
by  radiation  so  it  is  unlikely  that  a  transistor  will  be  struck  in  such  a 
manner  that  it  suffers  a  destructive  single  event  latchup  (SEL),  single 
event  gate  rupture  (SEGR),  or  single  event  burnout  (SEB). 

•  PIC  Single  Event  Upset  (SEU) 

o  Ions/Radiation  causes  a  transistor  to  flip  state 
o  Mitigation  strategy: 

■  Use  memory  with  hardware  ECC  and  scan  (read  all  memory 
sectors)  periodically 

•  On  failure  of  ECC,  mark  file  as  invalid  and  log  error  for  the 
next  download  session 

■  Scan  PIC  internal  memory  to  compute  ECC  internally 

•  On  failure,  return  to  bootloader  mode  and  reprogram  sector 
from  backup  copy 

o  Severity:  2.  An  SEU  is  a  temporary  condition  (no  hardware  damage)  so 
the  processor  or  memory  bank  can  be  reset  quickly.  The  other,  redundant 
PIC  connections  can  take  over  control  in  the  meantime, 
o  Likelihood:  4.  In  LEO,  it  is  highly  probably  that  a  number  of  SEU’s  will 
occur  over  the  duration  of  the  mission 

•  Inter-PIC  communications  failure 

o  CAN  bus  stops  working,  drops  packets,  or  corrupts  data  temporarily  or 
permanently  to  one  or  all  PICs. 
o  Could  be  due  to  a  software  or  hardware  problem 
o  Mitigation  strategy: 

■  RS-485  bus  might  be  usable  for  inter-pic  communications 

•  Would  require  a  software  update 

•  Would  reduce  the  frequency  the  avionics  system  could  the 
Sun  Sensors  and  control  the  Reaction  Wheels 

■  Memory  bank  is  an  alternative  communication  device. 

•  Already  used  as  a  full  storage  location  for  commands 
before  processing  by  any  chip 

•  Would  require  a  software  update  for  full  use 

•  Difficult  to  synchronize  access  to  a  communications  file 

•  Slow  to  push  messages 

■  Active  acknowledgement  of  packet  reception  (for  detection) 

■  Reset  of  non-responsive  PIC 

■  Replacement  code  upload  with  a  revised  implementation  of 
communication  protocol  and/or  hardware  interface  layer 
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o  Severity:  3.  Without  the  ability  for  the  PIC’s  to  communicate,  the 
effectiveness  of  the  redundant  system  would  be  significantly  reduced 
o  Likelihood:  1.  Significant  testing  before  launch  should  catch  any  software 
bug.  Wires  are  laid  out  as  traces  on  PCB  and  are  not  prone  to  mechanical 
disconnection  during  launch.  The  only  potential  threat  is  micrometeorites, 
which  we  do  not  expect  the  satellite  to  hit  and,  in  the  event  that  the 
satellite  does  encounter  one,  will  hopefully  be  stopped  by  the  aluminum 
structure  or  enclosure. 

•  RTOS  Software  deadlock  (or  livelock) 

o  Multiple  threads  become  stuck  in  a  race  condition  waiting  for  a  resource, 
o  Four  Conditions  for  Deadlock  (taken  from  Concurrency3  lecture  in  16.35 
by  Nicholas  Roy,  February  23rd,  2010) 

■  Mutual  exclusion  condition 

•  each  resource  assigned  to  1  process  or  is  available 

■  2.  Hold  and  wait  condition 

•  process  holding  resources  can  request  additional  resources 

■  3.  No  preemption  condition 

•  previously  granted  resources  cannot  forcibly  taken  away 

■  4.  Circular  wait  condition 

•  must  be  a  circular  chain  of  2  or  more  processes 

•  each  is  waiting  for  resource  held  by  next  member  of  the 
chain 

o  Mitigation  strategy: 

■  Eliminate  one  of  the  four  conditions  for  deadlock  from  the  system 
[the  preferential  order  for  eliminating  problems  is:  1.  address 
mutual  exclusion  (spool  everything  -  simplest  solution,  never  an 
issue)  2.  address  circular  wait  condition  (order  resources 
numerically)  3.  address  hold  and  wait  condition  (request  all 
resource  initially  and  simultaneously)  4.  address  no  preemption 
condition  (take  resources  away  -  generally  not  feasible)] 

■  Reset  task  or  entire  system  if  a  task  or  the  system  becomes 
nonresponsive  to  watchdog  messages 

o  Severity:  3.  If  the  system  or  a  task  becomes  nonresponsive  it  may  miss 
events  and  cause  the  entire  satellite  to  become  lost  or  fail  to  execute  tasks 
correctly.  Deadlocks  (and  livelocks)  are  very  difficult  to  debug  and  fix 
since  there  are  no  simple  tests  to  detect  them  and  are  often  impossible  to 
reproduce  the  same  way  twice 

o  Likelihood:  4.  Deadlocks  can  slip  into  the  most  innocent  code  and  there  is 
no  simple  way  test  for  their  existence  of  to  eliminate  them 

•  Wires  or  connectors  break  or  separate 

o  A  broken  connection  means  that  one  or  more  components  will  become 
inaccessible  to  the  avionics  system  control 
o  Could  be  due  to  the  vibrations  during  launch,  a  bad  solder  joint,  or  a 
partially  damaged  wire  (nicked  during  stripping  or  placement) 
o  Mitigation  strategy: 
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■  Use  many  low  pin-count  connector  with  locking  clips  or  screws 
instead  of  large  connectors  or  plain  wires 

■  Separate  redundant  components  onto  unrelated  connectors 

■  Visually  inspect  and  electrically  test  all  joints  during  and  after 
board  assembly  before  releasing  to  launch 

■  Choose  strong  connectors  and  plan  the  wiring  harness  to  eliminate 
tight  corners  and  sharp  bends 

■  Use  care  in  construction  of  the  final  board  and  wiring  harness 
o  Severity:  4.  One  or  more  components  will  be  completely  disabled. 

o  Likelihood:  1 .  With  proper  care  and  thought,  the  final  design  and 
construction  should  be  free  from  unnecessary  risks 

•  Memory  overflow 

o  If  too  many  picture  are  taken  between  comm,  passes  or  the  system  is 

unable  to  fully  relay  the  picture  and  telemetry  data  at  each  comm,  pass,  the 
memory  will  eventually  reach  capacity  and  “overflow” 
o  Overflow  could  also  occur  if  the  filesystem  is  leaking  file  sectors  through 
improper  space  management  or  a  processor  reset  occurring  during  writing 
o  Mitigation  strategy: 

■  Purchase  a  memory  card  well  in  excess  of  the  calculated  maximum 
(since  it  is  the  inexpensive  and  the  same  weight  and  volume) 

■  Lower  the  rate  of  pictures  when  the  memory  usage  level  reaches  a 
high-water  mark.  Also,  the  thruster  should  not  be  firing  and  thus 
few  pictures  will  be  needed  if  the  satellite  has  missed  several 
consecutive  communications  passes 

■  (critical  stage,  must  be  initiated  by  ground  command)  Reset  the 
memory  entirely  to  restart  with  a  fresh  and  clean  file-system 

■  Deletion  over  overwrite  of  less  critical  data  when  possible  or 
necessary 

o  Severity:  1.  The  full  data  stored  in  memory  has  a  high  degree  of 

redundancy  and  is  not  essential  to  the  mission.  Much  of  the  data  should  be 
reconstruct-able  by  extrapolation  of  remaining  data 
o  Likelihood:  2.  The  memory  is  considerably  oversized  for  the  expected 
amount  of  data  and  comm,  passes  are  both  sufficiently  frequent  and  high 
bandwidth  to  permit  a  full  download  of  the  captured  data  even  if  several 
passes  are  missed  or  a  portion  of  a  comm,  pass  is  missed 

•  Avionics  processes  an  invalid,  corrupted,  or  incorrect  command 

o  A  command  gets  misinterpreted  or  a  wrong  command  gets  processed  by 
the  avionics  system  due  to  either  a  communications  error,  a  storage  error, 
an  execution  error,  a  code  error,  or  a  user  error, 
o  Mitigation  strategy: 

■  Require  multiple  confirmations  of  critical-type  commands  (such  as 
decommissioning  /  fire-code,  mode  change,  and  engine  firing  -  see 
Ops  and  Comm,  sections) 

■  Include  redundant  information  in  transmissions  and  command 
encoding  to  detect  errors.  Confirm  upon  receipt  and  again  before 
execution  of  action 
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■  Log  details  of  the  failure 

■  Restart  or  disable  the  offending  process  or  request  a  retransmission 
of  the  invalid  command  packet 

o  Severity:  2.  The  severity  depends  upon  the  type  of  command,  but  typically 
will  be  transient  and  thus  have  only  a  small  effect  on  the  system 
o  Likelihood:  2.  The  confirmation  and  redundancy  safeguards  will  catch 
most  errors  before  they  are  executed 
•  Other  environmental  damage 

o  Thermal,  vibration,  impact,  or  radiation  conditions  exceed  the  operating 
tolerances  of  the  design 
o  Mitigation  strategy: 

■  Select  components  with  military  specifications  for  a  wide 
temperature  range  and  work  with  Thermal  Team  to  develop 
procedures  and  coatings  to  keep  components  within  the  desired 
temperature  range 

■  Process  the  board  according  to  AFRL’s  Procedures  for  Conformal 
Coating  of  Printed  Circuit  Boards  (available  from 
http://www.universitynanosat.net/NS6/?q=Documents/NS6) 

■  Subject  the  avionics  design  to  vibe  testing  before  and  after  system 
integration 

■  Simulate  errors  due  to  radiation  and  expose  the  board  to  high 
energy  particles  at  the  MIT  nuclear  reactor  to  verify  detection  and 
recovery 

■  Enclose  the  entire  avionics  system  in  a  Aluminum  enclosure 
o  Severity:  4.  Without  the  avionics  board,  the  mission  will  fail. 

o  Likelihood:  1 .  The  UNP  user’s  manual  and  extensive  simulation  and 
testing  greatly  reduce  the  likelihood  of  environmental  damage  occurring. 


TABLE  2.3-2:  SUMMARY  OF  AVIONICS  RISKS 


Component  Failure  Mode 

Severity 

Likelihood 

Risk  Level 

PIC  hardware  failure;  PIC  fails  to  respond 

4 

1 

MED 

PIC  SEU;  lons/Radiation  causes  a  transistor  to  flip 

2 

4 

MED 

Inter-PIC  communications  failure; 
Software/Hardware  implementation  error 

3 

1 

low 

RTOS  Software  Deadlock;  ThreadX  software 
implementation  error 

3 

4 

HIGH! 

Wire  separation;  Wiring  harness  breaks;  Solder 
connections  fail 

4 

1 

MED 

Memory  corruption;  Data  stored  in  memory 
becomes  unreliable 

1 

2 

low 

Memory  overflow;  Data  not  correctly  offloaded 
when  appropriate 

1 

2 

low 
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Invalid  command  processed;  Incorrect  software 
implementation 

2 

2 

low 

Environmental  damage  to  avionics  equipment; 
Heat/Vibration  reach  beyond  controllable  levels 

4 

1 

MED 

2.3.5  DSC  BOARD  (J.  NASH) 


The  system  layout  was  designed  in  coordination  with  the  ADCS  and  Power  team  leads  to 
determine  which  interfaces  are  critical  and  which  could  be  considered  redundant.  The 
connections  were  then  spread  out  across  the  dsPICs  in  an  attempt  to  balance  the  interface 
load  between  PIC1  and  PIC2  and  to  minimize  disruption  due  to  the  partial  or  total  failure 
of  a  single  microcontroller.  Pins  were  chosen  to  place  as  many  connections  to  a  given 
device  on  a  single  port  as  possible,  and  then  to  duplicate  that  choice  across  all  PICs. 

Avionics  chose  to  go  with  3  PICs  rather  than  a  single,  more  powerful  processor  because  it 
offers  redundancy  in  case  of  a  SEU  or  other  failure.  The  PICs  also  provide  a  large 
number  of  V O  pins.  The  current  design  makes  use  of  about  three  quarters  of  the  total 
available  pins.  Approximately  130  pins  will  be  connected  external  to  the  avionics  box  for 
signals,  power,  and  ground  connections  to  other  sub  team’s  components. 

Analog  inputs  were  allocated  evenly  across  PIC1  and  PIC2  so  that  the  ADC  converter 
could  be  disabled  on  the  ADCS  PIC  3  to  reduce  overhead  when  executing  the  Kalman 
Filter.  Small,  200  ohm  resistors  are  placed  on  each  of  the  thermal  IC’s,  voltage 
measurement,  and  current  measurement  input  lines  to  guard  against  electrical  shorts  from 
damaging  the  microprocessor. 

Each  microprocessor  can  access  the  onboard  1GB  NAND  memory  through  a  shared  SPI 
bus  that  is  connected  to  SPI  2  on  each  dsPIC.  Exclusive  access  to  this  bus  is  enforced  by 
a  bus  arbitrator  chip  (P/N  74F786)  and  tri-state  octal  buffers  (P/N  SN74AHC373DW). 
This  combination  helps  to  ensure  data  will  not  easily  be  accidentally  corrupted  during 
access  due  to  multiple,  simultaneous  attempts.  A  discrete  Secure  Digital  (SD)  card  was 
chosen  for  extra  memory  make  debugging  easier.  Since  the  card  is  removable,  and  a 
common  standard,  it  can  be  read,  verified  and  written  with  most  computers.  An  SD  card 
adaptor  has  been  chosen  for  the  PCB;  however,  a  SD  card  selection  has  not  been 
finalized.  Our  requirements  state  that  our  memory  must  have  sufficient  capacity  to  store 
telemetry,  log,  housekeeping,  task,  command/schedule,  and  imaging  data.  However,  since 
there  are  very  few  cards  produced  with  a  capacity  less  than  1GB  and  costs  are  quite  low 
(<  $25),  this  requirement  does  not  pose  an  issue.  The  sum  of  the  requirements  specify 
collecting  only  a  fraction  of  that  amount  of  data  between  communications  passes,  but  the 
additional  space  will  give  us  extra  margin  for  storing  data  so  that  data  will  not  be 
overwritten  even  in  the  occurrence  of  missing  multiple  communications  passes.  As  there 
is  no  difference  in  size  or  mass  for  the  additional  space  and  only  a  minor  cost  difference, 
there  is  no  disadvantage  to  over-sizing  the  memory. 

Our  requirements  state  that  the  selected  memory  must  be  fault  tolerant  and  long-lasting. 
This  is  derived  from  the  requirements  for  reliable  storage  of  system  data  —  such  as 
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pictures,  telemetry,  commands,  and  logs  —  which  are  important  for  the  mission,  so 
consideration  was  only  taken  of  memory  modules  that  came  with  documentation  (few 
manufacturers  make  this  readily  available)  and  specified  that  the  memory  had  a  built-in 
error  correction  code  (ECC)  which  transparently  detects  and  corrects  the  random  bit  flips 
that  are  likely  to  occur  due  to  radiation.  Transcend  Information,  Inc,  Apacer  Technology, 
Inc.,  and  SanDisk  all  seem  to  have  some  form  of  hardware  ECC. 

Each  PIC  is  provided  the  ability  to  reprogram  any  of  the  other  PICs  in  hardware  through 
their  run-time-serial-programming  interface  (RTSP).  Note  that  they  always  have  the 
ability  to  reprogram  themselves  though  the  In-circuit-self -programming  API  (ICSP). 

Since  each  PIC  has  three  inputs  for  data  connection,  each  PIC  is  connected  to  a  set  of 
programming  pins  on  each  of  the  other  PICs  and  one  set  external  to  the  board  for 
connecting  to  the  ICD2.  Since  there  is  only  one  reset  input  pin,  the  three  reset 
connections  are  joined  together  using  a  three  input  AND  gate  (P/N  CD74HC4075M)  with 
each  of  the  inputs  held  at  logic  high  using  a  pull-up  resistor  when  not  actively  being 
driven  low.  This  ensures  that  the  PICs  do  not  reset  except  when  specifically  being 
programmed. 

One  of  the  magnetometers,  the  IMU,  and  the  GPS  are  located  in  the  avionics  box  and 
connected  directly  to  the  board.  The  board  contains  the  footprint  connectors  for  the 
magnetometer  and  IMU  since  these  components  have  already  been  acquired.  Because  the 
GPS  is  too  expensive  to  purchase  early,  the  connections  to  the  GPS  does  not  need  to  be 
included  on  the  design  until  a  later  revision  of  the  board.  For  connecting  the  components 
that  are  external  to  the  box,  latching  low-profile  socket  connectors  with  strain  relief 
(AVX  Series  8290)  have  been  selected.  The  10-pin  version  of  this  connector  allows  a 
one-to-one  mapping  to  the  9-pin  (plus  shell)  d-sub  connectors  that  may  provide  the 
interface  between  the  avionics  board  and  components  that  are  external  to  the  avionics 
box.  If  necessary,  in  a  later  revision,  the  pin  counts  of  each  connector  can  be  revised 
upwards  to  reduce  the  number  of  connectors  required.  Since  ADCS  has  many  more 
components  than  can  be  connected  to  separate  ports,  even  across  all  of  the  PICs,  avionics 
requested  that  other  subteams  select  devices  that  can  communicate  over  SPI  or  RS-485 
and  then  multiple  devices  were  multiplexed  onto  SPI  1  and  UART  2  on  each  PIC. 

Because  the  operation  of  the  Propulsion  system  and  is  critical  to  a  successful  mission, 
and  it  depends  upon  working  control  over  a  Power  system,  all  power  controls  from  the 
avionics  system  are  duplicated  between  PIC1  and  PIC  2.  Then  they  are  combined  using 
an  OR  gate  (P/N  74AC1 1032D)  with  pull-down  resistors  on  the  inputs.  The  net  result  is 
that  either  PIC  is  able  to  turn  on  the  power  components.  If  one  PIC  becomes  stuck  with  a 
component  in  the  on  state,  the  other  PIC  can  force  that  PIC’s  reset  line  high  to  turn  off 
the  component.  The  analog  trim  for  the  heater  on  the  PPU  is  controlled  in  a  similar  way 
using  two  DAC  chips  (P/N  MCP4821)  with  their  outputs  summed  using  an  Op-Amp  (P/N 
MCP619-I/SL)  and  then  divided  by  3  to  make  the  maximum  output  voltage  be  1.1V, 
which  is  less  than  the  point  at  which  the  converters  would  break,  1.23V.  These 
components  were  chosen  because  they  are  manufactured  by  the  same  company  that 
makes  the  dsPIC,  Microchip,  and  their  output  was  within  our  specifications. 

The  camera  that  was  selected  communicates  over  UART,  however  all  6  UART  ports 
across  the  3  microcontrollers  are  already  occupied  by  other  important  devices.  The 
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decision  was  made  to  multiplex  the  camera  on  the  SPI  port  of  the  ADCS  PIC  3  using  a 
standard  SPI-to-UART  converter  chip  (P/N  MAX3100).  Since  the  camera  is  used 
relatively  infrequently  and  is  not  time-critical,  this  conversion  is  not  expected  to  overload 
this  PIC  with  data  that  would  hinder  its  performance  in  its  primary  task  of  executing  the 
Kalman  filter  state  estimation  and  feedback  control  tasks. 

Thermocouples  attach  to  an  isothermal  interface  on  the  exterior  of  the  avionics  box  that 
also  provides  2  reference  thermistors.  Exactly  half  of  these  devices  are  read  out  on  each 
of  PIC  1  and  PIC2.  The  circuitry  for  translating  the  voltage  difference  of  the  thermocouple 
to  absolute  voltages  is  part  of  the  avionics  board.  This  circuit  multiplies  the  difference  by 
100  and  then  biases  the  result  by  1.2V  so  that  positive  temperature  differences  (as 
referenced  against  the  thermocouple)  measure  as  voltages  above  1.2V  and  vice  versa. 
Refer  to  Microchip  document  AN844  copyright  2002  for  more  details,  noting  that  we 
believe  the  circuit  diagram  we  used  as  a  reference  for  our  circuit  design,  marked  Figure  3: 
Simplified  Digital  Circuit,  to  be  in  error. 

All  three  of  the  dsPICs  can  communicate  with  each  other  over  a  CAN  bus.  An  additional 
connection  to  the  CAN  bus  is  provided  on  the  lightband  connector  for  the  purposes  of 
reprogramming  and  debugging  the  hardware  after  launch  vehicle  integration  prior  to 
launch.  The  CAN  bus  is  a  logical  choice  for  this  communication  as  it  provides  a  robust 
and  communication  protocol  for  packetizing  and  transmitting  data  between  multiple  host 
microprocessors.  It  was  electrically  designed  for  use  in  the  noisy  environment  of  a  car 
due  to  its  use  of  differential  signaling  and  it  handles  collisions  automatically  through  the 
use  of  identifier  priority  levels.  Since  the  last  design  document,  Microchip  has  begun 
selling  a  new  revision  of  the  silicon  for  the  dsPIC  that  we  are  using  (now 
dsPIC33FJ256GP710A)  that  is  supposed  to  have  corrected  the  flaws  that  corrupted  prior 
attempts  to  use  the  full  capabilities  of  the  CAN  bus.  Tests  to  confirm  will  be  started  when 
the  coding  work  moves  from  focusing  on  a  single  dsPIC  to  developing  the  code  that 
controls  the  interactions  between  the  dsPICs.  The  largest  remaining  block  of  pins  on  each 
dsPIC  is  connected  to  an  array  of  FEDs.  There  are  4  FEDs  on  PIC  1,  2  FEDs  on  PIC  2, 
and  5  FEDs  on  ADCS  PIC  3.  There  are  also  FEDs  to  indicate  the  presence  of  +3.3V  and 
+5V  power  to  the  board.  On  the  final  construction  of  the  PCB  for  flight,  these 
components  will  simply  be  left  off  of  the  board  to  save  power. 

The  avionics  board  layout  is  designed  to  fit  exactly  into  the  space  currently  allocated  by 
the  structures  team.  The  maximum  allowable  size  is  4"  by  7”.  The  final  revision  of  the 
board  will  have  more  layers  for  the  purpose  of  thermal  conduction,  but  otherwise  the 
current  board  contains  all  of  the  flight  components  and  fits  in  the  space  allocated..  These 
external  connectors  will  be  a  combination  of  9-pin  or  25-pin,  d-sub  or  micro  d-sub 
connectors.  Refer  to  section  Error!  Reference  source  not  found,  for  the  wiring  harness 
diagram.  Please  also  refer  to  the  avionics  sections  of  the  Manufacturing  and  Integration 
plans.  The  tall  items  on  the  board  layout  are  designed  so  that  on  one  side  of  the  board,  the 
PDU,  Magnetometer  1,  and  IMU  will  fit  side-by-side  for  the  best  use  of  volume.  On  the 
opposite  side  (facing  outwards  on  the  satellite)  the  two  modems  are  placed  side-by-side 
and  made  to  be  in  thermal  contact  with  the  interior  of  the  avionics  box  wall  to  remove 
heat  from  them.  Thermal  paste  will  be  applied  to  the  modems  on  the  surface  in  contact 
with  wall  of  the  avionics  box  to  increase  the  rate  of  heat  transfer  and  prevent  when 
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communicating.  Please  refer  to  Structure’s  layout  for  the  positions  of  the  remaining 
components  that  have  some  connection  to  the  avionics  microcontrollers. 

The  remaining,  shorter  components  are  laid  out  on  the  board  in  the  remaining  space 
between  the  tall  components  using  two  general  principles.  One,  related  components  are 
located  physical  close  to  each  other  and,  if  possible,  placed  in  a  marked  rectangle,  for 
easier  assembly  and  to  reduce  the  amounts  of  long  distance  wiring  on  the  board.  Two, 
similar  resistors  are  lined  up  in  banks  of  identical  values  to  speed  up  the  hand  assembly 
process  while  reducing  errors  in  the  selection  and  placement  of  these  component. 

The  thermocouple  circuit  is  placed  to  one  side  of  the  board  that  requires  less  wiring  to 
provide  better  noise  characteristics.  Tests  will  be  performed  to  verify  that  the  stability  of 
their  measurements  are  within  bounds  and  are  not  affected  by  the  power  flow  to  the 
modems  or  other  signal  currents.  If  this  criterion  cannot  be  met  with  the  current 
configuration,  other  options  for  isolating  the  thermocouple  inputs  fromsignal  noise  (until 
they  have  been  amplified)  will  have  to  be  considered. 

The  filtering  capacitors  on  the  3.3V  line  are  placed  directly  over  the  input  line  to  ensure 
the  incoming  signal  is  sufficiently  free  of  noise  that  may  disrupt  a  component  such  as  the 
PICs.  Similarly,  the  crystal  resonators  and  accompanying  capacitors  are  placed  near  the 
pin  they  connect  to,  in  order  to  improve  signal  quality.  These  components  are  also  routed 
by  hand  before  running  the  auto-router  to  ensure  they  are  connected  correctly  to  the 
correct  pin  and  not  another  random  nearby  source  that  looks  electrically  equivalent,  but 
would  not  provide  the  same  signaling  characteristics. 

Once  the  components  are  placed  in  an  efficient  manner,  the  auto  router  tool  in  Altium  is 
able  to  create  the  board.  Many  of  the  features  on  the  board  have  been  selected  to  exactly 
meet  the  minimum  tolerances  specified  by  our  preferred  manufacturer,  Advanced 
Circuits  (www.4pcb.com),  for  standard  4-layer  boards.  This  manufacturer  is  very 
responsive  to  requests  by  email  and  phone,  they  provide  an  affordable  student  discount 
on  small  orders,  and  have  already  produced  other  printed  circuit  boards  for  the  MIT 
Satellite  Team  Avionics,  Communications,  and  Power  subteams.  The  avionics  board  is 
composed  of  two  internal  power  planes  of  3.3V  and  ground,  and  two  exterior  signal 
planes.  The  final  board  will  be  composed  of  more  layers  to  allow  for  the  printing  of  two 
thermally  conductive  layers  connected  to  ground  and  more  signal  layers,  if  necessary,  to 
compress  the  board’s  footprint.  Several  of  the  components  on  the  board  require  a 
maximum  clearance  distance  of  7mil  between  traces,  which  still  leaves  a  small  margin  on 
the  manufacturer’s  minimum  of  6mil.  Using  standard  online  lookup  tables  for  trace  width 
a  trace  width  of  8mil  is  sufficient  for  most  components  on  the  board.  Because  space  is  a 
vacuum,  the  temperature  specifications  for  an  internal  plane  trace  are  used  (the  external 
numbers  assume  convection  cooling),  giving  a  maximum  current  of  0.3  amps  at  this 
thickness.  Thus,  only  the  modem  power  supply  lines  and  structure’s  linear  actuator  power 
feed  will  require  thicker  traces.  Using  the  same  calculator,  it  can  be  found  that  a  trace 
width  of  12  mil  is  sufficient  to  handle  the  currents  driving  the  linear  actuator  and  45  mil 
traces  are  sufficient  to  handle  the  currents  for  the  modem.  These  traces  were  routed  by 
hand  before  running  the  auto-route  function. 
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The  current  avionics  board  is  composed  of  2  signal  layers  on  the  top  and  bottom  and  2 
power  planes  in  the  middle  connected  to  3.3V  and  Ground.  This  will  allow  us  to  alter 
traces  during  testing  if  something  does  not  work  properly.  After  we  gain  confidence 
through  experience  with  the  board  layout,  the  board  will  be  designed  and  manufactured  to 
include  more  internal  layers,  possible  internal  signal  layers  and  thermal  (ground)  planes. 
The  board  layout  can  be  compressed  further  at  that  stage  to  better  fit  within  the  satellite 
structure  limits.  Additionally,  internal  signal  layers  will  allow  the  placement  of  thermal 
pads  beneath  any  component  that  consumes  a  noticeable  amount  of  power.  The  list  of 
such  components  definitely  includes  all  of  the  dsPICs  and  the  oscillators.  Thermal  team’s 
help  will  be  needed  to  determine  which  other  components  require  the  extra  cooling  help 
of  a  thermal  pad. 


2.3.6  WIRING  HARNESS  (S.  GOMEZ) 


CASTOR’S  wiring  harness  is  a  crucial  part  of  the  structural  and  avionics  design  of  the 
satellite.  Now  that  all  of  the  components  on  the  satellite  have  been  chosen  and  the 
avionics  board  design  has  been  completed  the  plans  for  navigating  wires  across  the 
satellite  can  be  completed. 

Some  of  the  sensors  (i.e.  IMU  and  Magnetometer)  are  being  housed  within  the  Avionics 
box  as  well  as  the  communications  Modems.  This  greatly  simplifies  the  wiring  that  must 
travel  across  the  span  of  the  satellite.  However,  there  are  still  several  major  components 
that  exist  on  all  corners  of  the  structure.  The  wiring  plan  will  consist  of  several  locations 
for  wiring  harnesses  to  be  strategically  placed  around  the  satellite  to  organize  and  guide 
the  wires  to  and  from  the  avionics  box,  battery  box,  and  other  components. 


Major  considerations  for  the  wiring  harness  are  included  below. 


Component  Name 

Number  of  Components 

Number  of  Avionics  Connections 

Temperature  Sensors 

14 

2  lOpin  connectors 

Thermo  Couples 

6 

2  lOpin  connectors 

Reaction  Wheels 

3 

1  lOpin  connector 

Sun  Sensors 

4 

4  lOpin  connectors 

Camera 

1 

1  16pin  connector 

Linear  Actuator 

1 

2  4pin  connections 

Antennae  Cables 

1 

1  Cable 

Battery  Box 

1 

(PDU  Power)  40pin  +  (PDU  Data) 
16pin  +  (PPU)  20pin 

TABLE  2.3-3:  MAJOR  CONSIDERATIONS  FOR  THE  WIRING  HARNESS 


Current  Plan  for  the  wiring  harness: 


16.83  CASTOR  Design  Document 


Page  105 


November  18,  2010 


Large  bundles  of  wires  will  travel  from  bottom,  middle,  and  top  of  avionics  box. 

Bundle  from  bottom  will  split  toward  two  reaction  wheels  at  the  base  of  the  structure, 
toward  nearby  sun  sensor,  and  thermal  sensors  at  the  base  of  the  tank. 

Bundle  emanating  from  center  of  avionics  box  will  connect  to  thermal  sensors  on  the  tank 
clamps  and  fins.  This  bundle  will  then  split  to  extend  to  thermocouples  located  on  solar 
arrays  and  battery  box  and  reaction  wheel  above. 

Top  bundle  will  split  and  connect  to  the  suns  sensors  nearest  to  it.  It  will  also  wrap 
around  to  thermal  sensors/thermocouples  near  cathode  and  anode  and  continue  to  the 
camera  box  and  final  sun  sensor. 

These  wire  paths  must  have  several  connection  points  along  their  routes  to  adequately 
secure  the  bundles  of  wires  as  they  approach  their  destinations.  The  locations  of  these 
harnesses  are  the  core  of  the  wiring  plan  throughout  the  satellite. 

UPDATE:  The  wiring  harness  was  built  over  summer  2010.  However,  nobody  from  that 
time  frame  is  around  to  describe  it  in  more  detail  for  this  section. 


2.3.7  REALTIME  OPERATING  SYSTEM  API  (B.  KROESE) 

A  satellite  must  run  semi-autonomously  throughout  it  s  operational  life  using  real-time 
operating  systems  to  control  the  organization  and  data  of  the  system.  Naturally  there  are 
many  different  processes  which  must  occur  concurrently  controlling  items  such  as 
sensors,  data  manipulation,  and  packet  transmission.  Satellites  handle  this  concurrency 
through  a  multithreading  system  assigning  different  tasks  to  individual  threads.  Keeping 
these  considerations  in  mind,  ThreadX  by  Express  Logic  was  chosen  as  the  real  time 
operating  system  for  the  CASTOR  embedded  system.  This  C  based  software  kernel 
manages  a  system  of  tasks  controlling  the  satellite’s  its  internal  processes  while  also 
interacting  with  sensors  and  data  transmission. 

The  avionics  hardware  centers  on  the  three  16-bit  dsPIC33F  microcontrollers.  Each  of 
these  components  runs  a  separate  copy  of  the  operating  system  code  while  controlling 
sensors  and  computational  aspects  of  the  satellite.  Repetition  allows  the  system  to  check 
and  recover  from  single  even  upsets.  Figure  2.3.7 -1  shows  the  different  operations  which 
are  defined  and  regulated  by  the  microcontrollers.  The  main  purpose  of  the  ThreadX 
technology  is  to  manage  how  these  tasks  are  executed  using  interrupts  from  each  of  the 
components  to  move  between  different  processes. 
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Commissioning 


Regular  Operations 

7! 


Operations  Task 


Tasks 


Interrupts 


Specific  Threads 


Operate  Engine 


Sensor  Recording 

i  A 


Sensor  Management 


TX  Data 

*1 

RX  Data 

FIGURE  2.3-11:  OPERATING  SYSTEM  STRUCTURE 

The  satellite’s  lifespan  can  be  grouped  into  two  different  sections:  the  initial  start  up  and 
then  the  steady  state  or  regular  operations.  Both  are  defined  within  the  real  time 
operating  system.  ThreadX  simplifies  this  process  through  its  issued  library.  The  user 
specifies  the  different  processes  and  threads  then  calls  the  ThreadX  software  to  initialize 
all  of  these  processes.  The  following  Figure  2. 3. 7-2  shows  the  commissioning  process. 
The  user  calls  tx_kernel_enter  within  its  main  function  to  turn  control  to  the  ThreadX 
software.  This  in  turns  calls  the  tx_application_define  which  initializes  all  processes  in 
the  microcontrollers.  The  real  time  operating  system  then  enters  its  steady  state  where  is 
remains  throughout  the  rest  of  its  lifespan. 
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FIGURE  2.3-12:  PIC  BREAKDOWN 


One  of  the  most  important  features  of  the  ThreadX  software,  aside  from  its  ability  to 
distribute  control  to  each  parallel  process,  is  its  ability  to  prioritize  each  of  these  tasks  and 
integrate  them.  Since  the  satellite  must  perform  many  simultaneous  operations  it  is 
constantly  receiving  requests  or  interrupts  from  multiple  components.  ThreadX  requires 
the  assignment  of  priorities  to  each  thread  and  interrupts  to  ensure  that  the  most  important 
tasks  are  executed  before  other  others.  Execution  priority  levels  between  1  and  1023  are 
available.  Figure2.3-13  shows  the  priority  hierarchy  of  CASTOR’s  interrupts  and  how 
they  will  be  handled. 
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FIGURE  2.3-13:  PRIORITY  HIERARCHY 
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A  thread  should  consist  of  the  following  elements: 


•  A  header  that  defines  or  described  the  following 

o  Resources  invoked  by  the  task  (timers,  ports,  devices,  memory,  etc.) 
o  Priority  level  of  the  task  (in  relative  terms  and  the  absolute  number) 
o  Communication  structs  (if  passing  data  back  to  the  ground) 
o  Description  of  data  logging  formats  and  rates 

•  Local  variables 

•  Any  initialization  code  that  must  be  run  immediately  on  startup 

•  Command  and/or  timer  interrupt-driven  processing  loop 

•  Hardware-interrupt  signal  processing  (the  amount  of  code  here  should  be  kept  to 
an  absolute  minimum,  with  the  majority  of  the  processing  done  in  the  normal 
processing  loop) 

•  Resource  locks  (these  should  be  kept  to  an  absolute  minimum,  and  avoided  where 
possible  by  using  a  unique  thread  for  each  device  to  prevent  access  conflicts,  but 
they  will  certainly  be  necessary  for  the  shared  SPI  bus) 

The  full  list  of  tasks  necessary  for  satellite  operation,  which  need  to  each  be  converted  to 
a  thread  on  the  respective  dsPIC,  are  outlined  below  for  reference  (grouped  roughly  in 
terms  of  input-only,  input/output,  output-only  tasks) 


A.  On  dsPIC  1 

1 .  Thermal  (-sensors  and  - 
couples) 

2.  Power  sensors 

3.  Magnetometer 

4.  Watchdogs 

5.  Modem 

6.  Memory 

7.  CAN 

8.  Debugging  LEDs 

9.  Torque  Coil 

10.  Linear  Actuator 

11.  Power  converter 
activation  signals 

i.  Also  controls 
propulsion  system 

ii.  Includes  DAC 

B.  On  dsPIC  2 

1 .  Thermal  (-sensors  and  - 
couples) 

2.  Power  sensors 

3.  Magnetometer 

4.  IMU 


5.  Watchdogs 

6.  Modem 

7.  Memory 

8.  CAN 

9.  Debugging  LEDs 

10.  Torque  Coil 

11.  Power  converter 
activation  signals 

i.  Also  controls 
propulsion  system 

ii.  Includes  DAC 

C.  On  dsPIC  3 

1.  Control  Loop 

2.  Kalman  Filter 

3.  GPS 

4.  Sun  Sensors 

5.  Reaction  Wheels 

6.  Camera 

7.  Watchdogs 

8.  Memory 

9.  CAN 

10.  Debugging  LEDs 

11.  Torque  Coils 
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The  system  will  also  need  to  keep  track  of  certain  elements  of  global  data  that  are  necessary 
across  many  threads.  These  variables  will  be  propagated  to  the  other  dsPICs  across  the  CAN  bus. 
This  will  allow  every  dsPIC  simple  and  transparent  access  when  any  thread  requires  their  values. 
The  list  of  variables  that  this  applies  to  is  provided  below.  Other  variables  are  local  to  their 
thread  and  should  not  be  accessed  by  another  thread.  They  may  be  made  accessible  to  another 
thread  via  the  message  passing  and  notification  architecture  that  ThreadX  provides,  or  by 
explicitly  extending  the  enumerated  list.  These  structures  should  all  be  defined  in  the  header  file 
“main.h”. 

•  Analog  voltage  readings  (the  raw,  unconverted  values) 

•  Whether  or  not  the  satellite  is  in  the  sun  (0=Eclipse) 

•  Whether  or  not  the  satellite  is  in  a  safe  state  to  fire  the  thruster,  broken  out  by  possible 
failure  parameter  (0=NOT  OK  to  fire) 

•  Magnetometer  readings 

•  IMU  Readings 

•  Attitude  and  position  state  data 

•  Time  bias  (synchronized  between  the  PICs  infrequently  and  on  startup) 


2.3.8  SD  CARD  API  EXAMPLE 


Access  to  the  SD  Card  is  buffered  in  local  flash  memory  on  each  dsPIC  to  facilitate  easy  and  fast 
access.  Because  access  to  the  SD  memory  is  shared  across  all  3  dsPICs  processors,  the  hardware 
design  includes  a  request  access  bus  enable  that  blocks  access  to  the  memory  until  the  dsPIC 
requests,  and  is  granted,  access.  To  ensure  that  threads  do  not  stall  whenever  they  need  to  write 
to  the  flash,  data  for  writing  is  first  buffered  into  the  internal  flash  memory  on  the  dsPIC,  and 
written  to  the  SD  Card  when  it  becomes  available.  It  is  necessary  to  buffer  using  the  flash 
memory  first  since  there  is  not  enough  space  in  the  data  ram  to  provide  a  buffer  of  sufficient  size 
given  the  need  to  be  executing  a  number  of  threads  and  other  routines  (there  is  28KB).  There  is 
256KB  of  flash  memory,  less  than  half  of  which  is  needed  for  the  actual  program,  so  the 
remainder  can  be  used  as  buffer. 

We  have  chosen  to  implement  a  first-in-first-out  (FIFO)  circular  buffer  structure  for  the  SD  write 
buffer.  New  data  is  added  to  the  tail  and  old  data  is  read  from  the  head.  Writing  to  flash  provides 
an  interesting  challenge  since  data  must  be  written  in  128  byte  chunks  (“a  row”),  but  it  must  be 
erased  before  it  can  be  written.  Unfortunately,  it  can  only  be  erased  in  1024  byte  chunks  (“a 
page”).  Thus,  items  can  only  be  added  to  the  buffer  if  there  is  a  sufficient  gap  to  the  next  item. 
Additionally,  before  starting  on  a  new  page,  the  entire  page  must  first  be  erased. 

We  chose  to  have  data  written  to  the  buffer  in  128  bytes  chunks.  Because  of  the  restrictions  listed 
above,  we  needed  to  choose  a  multiple  of  128  and  a  factor  of  1024.  The  choice  of  128  bytes  is 
expected  to  make  the  most  efficient  use  of  flash  space  since  that  figure  is  greater  than  the 
expected  value  for  the  number  of  characters  that  will  need  to  be  written  in  a  typical  step  to  one 
file.  This  size  includes  both  a  header  of  34  bytes  and  98  bytes  for  data.  The  header  contains  the 
information  on  the  number  of  byte  values  in  this  array,  the  sequence  number  of  the  write,  the 
offset  at  which  to  write  the  values,  and  30  characters  for  specifying  the  file  name,  including  its 
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path.  The  offset  can  be  a  number  from  0  to  OxFFFE  (inclusive)  and  will  result  in  the  data  being 
written  at  that  location  in  the  file.  Alternatively,  an  offset  of  OxFFFF  can  be  specified  which  will 
result  in  an  append  operation.  If  both  the  offset  is  0  and  the  number  of  characters  is  0,  the  file 
will  instead  be  deleted. 

Reading  the  data  is  much  more  straightforward  than  writing  since  any  chunk  can  be  read 
independently.  To  enable  recovery  and  error  detection,  after  reading  the  data  block,  the  first  row 
is  set  to  zero.  Thus,  by  scanning  the  first  integer  of  each  block,  the  program  can  determine  the 
state  of  that  block.  When  erased,  the  memory  is  set  to  all  1  ’s  (OxFFFF).  When  writing,  bits  can 
be  flipped  from  1  to  0,  but  not  vice-versa.  Thus  all  0’s  (0x0000)  is  used  as  a  flag  that  the  chunk 
has  been  filled  and  read,  but  not  yet  erased.  If  (when)  the  dsPIC  is  reset,  it  can  scan  through  the 
space  allocated  to  the  circular  buffer  and  read  these  flags  to  locate  the  contiguous  space  that 
contains  real  data,  or  determine  that  the  buffer  was  previously  empty. 

The  ADC  module  continuously  measures  the  voltages  on  the  analog  input  pins,  but  these  values 
are  only  read  out  on  a  periodic  timer  interval  (currently  specified  as  0.2  Hz  by  the  Power  and 
Thermal  teams).  The  Magnetometer  and  IMU  values  are  also  read  their  values  at  a  periodic  rate. 
(Other  sensors  will  be  read  periodically  as  well,  but  these  are  already  known  to  be  working  and  a 
full  list  can  be  found  in  the  previous  section  of  the  design  document,  with  the  details  on  each 
given  in  their  respective  sections  by  sub  team).  Upon  reading  of  these  sensors,  the  values  are 
immediately  stored  in  a  global  buffer  and  synchronized  across  the  3  dsPICs  using  the  CAN  bus. 
Saving  them  into  a  local  RAM  buffer  enables  simple  and  rapid  access  to  any  of  these  values  by 
any  process  on  any  dsPIC.  Since  the  CAN  bus  operates  at  500kbps,  it  should  have  plenty  of 
excess  capacity  to  handle  this  slow  rate  of  update.  Making  the  data  continuously  updated  and 
available  in  memory  also  eliminates  the  need  for  request/response  packets,  and  the  overhead 
associated  with  generating  and  processing  them.  The  full  list  of  variables  that  this  currently 
applies  to  can  be  found  in  the  previous  section  of  the  design  document. 


2.3.9  SOFTWARE  INTERFACES/  DEVICE  API  (L.  DE  LA  GARZA) 


See  the  Interface  Control  Documents  for  specific  functions  controlling  particular  hardware,  as 
well  as  pinout  diagrams  and  specifications. 

In  general,  control  of  hardware  involves  five  categories: 

1.  Initialization  or  setup 

In  this  kind  of  operation,  the  first  interaction  with  the  device  is  established.  In  this  operation,  the 
pins  on  the  dsPICs  associated  with  the  device  are  configured  correctly  (tristate,  high/low,  clock 
settings,  etc.).  Additionally,  if  there  are  any  initial  commands  that  must  be  sent  to  the  device, 
such  as  a  Configuration  operation,  those  might  be  covered  here.  The  convention  is  for  this 
function  to  contain  “Init”  or  “init”  somewhere  in  the  name,  and  to  have  no  arguments. 

2.  Wait/idle 

Certain  devices  can  be  set  to  operate  in  low-power  modes,  maintaining  their  configured  settings. 
The  magnetometer,  for  example,  is  capable  of  entering  sleep  mode  for  an  indefinite  amount  of 
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time;  when  awoken  it  is  capable  of  immediately  taking  readings,  without  having  the  dsPICs  need 
to  reset  any  hardware  settings  of  the  magnetometer.  The  convention  for  this  function  is  to 
contain  “idle”,  “sleep”,  or  “wait”  within  the  name,  and  possibly  possess  arguments. 

3.  Read/ Write 

Sensors  and  storage  are  capable  of  sending  data  to  or  receiving  data  from  the  dsPICs.  These 
functions  must  be  called  after  proper  initialization  and  configuration  operations.  The  names, 
arguments,  and  return  types  of  these  functions,  by  necessity,  have  no  strict  conventions. 

4.  Operate/execute 

These  kinds  of  operations  carry  out  the  necessary  activities  to  ensure  the  success  of  the  mission  - 
actuating  the  torque  coils,  controlling  the  power  switches,  taking  pictures  with  the  camera, 
sending  data  to  the  modems,  and  so  on.  The  names,  arguments,  and  return  types  of  these 
functions,  by  necessity,  have  no  strict  conventions,  but  usually  it  is  a  good  idea  to  have  the  name 
of  the  component  performing  the  action  within  the  function  name. 

5.  Configuration 

In  this  operation,  operating  settings  of  the  device  are  set.  Examples  of  this  operation  include 
setting  camera  resolution  or  oscillator  speed  in  the  magnetometer.  This  kind  of  operation  should 
happen  occasionally,  as  determined  by  mission  logic  or  commands  sent  from  the  ground. 


2.3.10  SOFTWARE  STATUS  (L.  DE  LA  GARZA) 


As  of  16  April  2010,  operating  code  of  the  PAC  and  Groundstation  is  incomplete.  The  current 
status  of  the  code  is  expanded  in  Table  2.3-4.  All  items  needs  to  be  green  (preferably  dark  green) 
before  launch,  where  green  is  used  to  indicate  a  functional  segment  of  code.  Other  colors  were 
chosen  to  give  an  intuitive  understanding  of  the  current  work  focus  on  the  components  and  their 
importance.  The  comments  then  go  into  further  detail  on  the  status  and/or  function  name  to 
provide  helpful  information  from  the  last  person  to  work  on  the  functionality  implementation. 


Function 

Status 

Comments 

Ability  to 
reprogram  (lab) 

Done 

ICD2  commercial  PIC  re-programmer  was  made  functional 
for  our  design  by  83x  class. 

Ability  to 
reprogram  (other 
PIC) 

ADC 

Done 

May  need  to  check/revise  timing  of  samples.  In  RTOS,  this 
sample  collection  may  be  done  in  a  thread  instead  of  an 
interrupt. 

CAN 

Mostly 

Receive  is  working,  buffered.  Transmit  has  many  issues 
(incorrect  packet  ordering,  no  buffer,  busy-wait  stall,  loss  of 
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working 

packet  SID’s)  which  are  most  likely  related  to  hardware 
errata  number  10  for  dsPIC33FJXXXGPX06/X08/X10 
family  of  processors. 

UART 

Working 

Buffered  bidirectional  for  both  U1  and  U2 

SPI 

Working 

Bidirectional  flow  that  triggers  off  of  the  DRDY  pin 

External  memory 

Have  selected  SD  memory;  unimplemented 

Watchdogs 

On  hold 

Needs  to  include  monitors  on:  code  integrity,  code  not  in 
lockup,  code  not  in  error  condition,  other  PIC  responding 
(over  CAN),  configure  ThreadX 

PIC  Flash 

Simulation  of  code  storage  works;  error  correction 
unimplemented 

SEU  logic 

Error  detection/correction  unimplemented 

RTSP  (Run  time 
serial 

programming) 

Partially 

working 

83x  class  demonstrated  a  direct  RTSP  reprogramming  over 
serial.  Much  of  the  code  for  a  buffered  write  is  in  place,  but 
untested  and  configuration  registers  are  probably  wrong. 
Possibly  want  to  convert  to  RTSP2  for  faster  reprogramming 
times. 

ICSP  (In-circuit 
self 

programming) 

On  hold 

Requires  separate  bootloader  code  architecture,  in  parallel 
with  the  main  DSC  code,  which  can  be  written  into  low 
memory  and  then  dropped  into  to  reprogram  the  rest  of  the 
PIC’s  memory. 

Linear  Actuators 

Mostly 

working 

Code  executes  correctly,  behavior  of  linear  actuators  is  far 
from  ideal  (low  precision,  unstable  positioning  for  small 
distances,  large  power  draw  to  hold  large  distances  (beyond 
physical  maximum) 

Thermal  Sensors 

Working 

Tested  the  measurement  of  several  thermal  sensors  and 
received  acceptable  (and  stable)  voltage  measurements. 

Thermocouples 

Torque  Coil 

Mostly 

working 

Code  tested  to  operate  torque  coils.  Creates  a  scalable 
bidirectional  magnetic  field.  Needs  integration  into  PAC. 

Magnetometer 

Working 

Code  tested  and  verified  for  collecting  three  axis 
magnetometer  data. 

Voltage  Sensors 

Mostly 

Code  written  to  sample  ADC  data  for  value  of  voltage 
dividers  for  the  actual  voltage  at  the  DC/DC  converter.  Code 
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working  is  awaiting  formal  test  session 

Current  Sensors  Mostly  Code  written  to  sample  current  sensors  at  DC/DC  converters, 
working  Code  is  awaiting  formal  test  session. 


Power  MOSFETs  Untested  Implemented;  proper  pin  registers  have  not  been  set. 


Communications  - 
transmission 


Communications  - 
groundstation 


Communications- 

MIT 

groundstation 


IMU 


Reaction  Wheels 


GPS 


Sun  Sensors 


Camera 


Untested 


Receives,  validates,  and  acknowledges  packets  correctly. 
Need  to  incorporate  lookup  table  with  task  registration  after 
integrating  RTOS).  Complete  command  interpretation  must 
be  fleshed  out.  Limited  validation  of  packets  can  be 
improved.  CRC  revision  needs  completion.  New 
segmentation  protocol  unimplemented. 

Receives,  validates,  and  acknowledges  packets  correctly. 
CRC  revision  needs  completion.  New  segmentation  protocol 
unimplemented.  Full  packet  vocabulary  must  be  fleshed  out. 
Image  transmission  to  MIT  must  be  implemented.  Code 
upload  must  be  implemented. 

Full  packet  vocabulary  must  be  fleshed  out.  Image  reception 
must  be  implemented.  Code  upload  must  be  implemented. 


Code  for  reading  the  accelerometer  and  gyroscope  data  from 
the  IMU  has  been  written.  This  code  is  awaiting  a  test 
session  for  verification. 


Camera  code  from  the  manufacturer  has  been  converted  to 
work  with  dsPIC.  Awaiting  flash  memory  to  perform  test  of 
operability. 


Time 


On  hold 


Tracking  current  time  using  GPS 


ThreadX  /  RTOS  Untested  Source  code  acquired;  thread  management  not  configured 


Message  passing  Untested  Not  evaluated/configured. 


RPC  (remote  Untested  Not  evaluated/configured, 

procedure  call) 

Ops  code  Full  set  of  mission  procedure  unimplemented. 
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Ops  code- 

comissioning 

logic 

Ops  code  -  power 
management  logic 

Ops  code  - 
thermal 

management  logic 

Ops  code  -  engine 
logic 

Ops  code  - 
command  log 

Command  list,  telemetry,  file  system 

Xenon  Feed 

System  logic 

ADCS  Control 
Logic 

On  hold 

Waiting  for  ADCS  development :  propagator,  estimator, 

EKF,  control  law 

TABLE  2.3-4:  STATUS  OF  CODE 


2.4  COMMUNICATIONS 


2.4.1  REQUIREMENTS  (S.  PARRA) 


Below  is  the  updated  requirements  verification  matrix  for  the  CASTOR  communication 
subsystem..  A  green  status  indicates  that  the  requirement  has  been  fully  met  by  the 
communication  subsystem.  A  yellow  status  indicates  that  the  requirement  has  been  met,  but  not 
fully  verified,  and  further  testing  is  needed  to  ensure  verification.  A  red  status  indicates  that  the 
requirement  has  not  been  met.  Most  requirements  have  been  met;  however  further  testing  still 
needs  to  be  done  to  verify  requirements.  Multiple  services  also  still  need  implementation  such  as 
packet  retransmission,  queuing,  and  command  interpretations. 


Requirement  Details 


Status 


1 


The  communications  system  shall  provide  the  ability  to  transmit  and 
receive  data 
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1.1 

1.1.1 

1.2 

1.2.1 

1.3 

1.3.1 

1.4 

1.4.1 

2 

2.1 

2.1.1 

2.1.2 

2.2 

2.2.1 

2.3 

2.3.1 

2.4 

2.4.1 

3 


The  communications  subsystem  shall  provide  the  ability  to  transmit 
telemetry  and  picture  packets  from  the  satellite  to  the  ground  station. 
The  communications  subsystem  shall  be  equipped  with  at  least  one 
antenna  and  one  modem  on  the  satellite. 

The  communications  subsystem  shall  provide  the  ability  for  the 
ground  station  to  receive  telemetry  and  picture  packets  from  the 
satellite. 

The  communications  subsystem  shall  be  equipped  with  a  dish  and  a 
modem  at  the  ground  station. 

The  communications  subsystem  shall  provide  the  ability  to  transmit 
commands  from  the  ground  station  to  the  satellite. 

The  communications  subsystem  shall  be  equipped  with  a  dish  and  a 
modem  at  the  ground  station. 

The  communications  subsystem  shall  provide  the  ability  for  the 
satellite  to  receive  commands  from  the  ground  station. 

The  communications  subsystem  shall  be  equipped  with  at  least  one 
antenna  and  one  modem  on  the  satellite. 

The  communications  system  shall  be  able  to  establish  a  robust  and 
periodic  link 

The  communications  subsystem  shall  recognize  correct  packets  from 
incorrect  packets  and  be  able  to  request  retransmission  if  the  packet  is 
faulty. 

The  link  layer  protocol,  from  the  modem,  shall  be  able  to  recognize 
correct  packets  from  incorrect  packets  and  be  able  to  request 
retransmission  if  the  packet  is  faulty. 

The  upper  layer  protocol,  from  the  software  on  the  satellite  and 
ground  station,  shall  be  able  to  recognize  correct  packets  from 
incorrect  packets  and  be  able  to  request  retransmission  if  the  packet  is 
faulty. 

The  satellite  shall  be  able  to  receive  a  set-up  ack  from  the  ground 
station  and  start  a  communications  link 

The  modem  shall  be  able  to  wake  up  from  sleeping  mode  when 
commanded  to  so  as  to  start  a  communications  link. 

The  communications  subsystem  shall  be  able  to  store  packets  to 
prevent  overflow. 

The  communications  protocol  shall  be  able  to  set  up  packet  queues 
on  the  satellite  and  the  ground  station. 

The  communications  subsystem  shall  be  able  to  identify  lossy 
packets  and  out  of  order  packets. 

The  communications  protocol  shall  be  able  to  identify  lossy  packets 
and  out  of  order  packets. 

The  communications  subsystem  shall  be  able  to  support  a  bandwidth 
and  data  rate  necessary  to  transmit  all  telemetry  (67bps)  and  pictures 
(2  per  orbit  640*480  pixels). 
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3.1 

3.2 

4 

4.1 

4.2 

5 


The  communications  subsystem  shall  transmit  at  1 15.2  kbps 

The  communications  subsystem  shall  have  a  bandwidth  of  2.4GHz 

The  communications  subsystem  shall  be  fully  redundant 

The  communications  subsystem  shall  be  equipped  with  2  antennas 

The  communications  subsystem  shall  be  equipped  with  2  modems 

The  communications  subsystem  shall  be  able  to  encrypt  data  packets 
TABLE  2.4-1:  COMMUNICATIONS  REQUIREMENTS 


2.4.2  OVERVIEW  (S.  PARRA) 


The  subsystem  consists  of  two  redundant  communication  mechanisms.  The  first  mechanism 
consists  of  two  antennas  connected  to  one  of  the  modems  via  a  splitter.  This  modem  is  then 
connected  to  one  of  the  dsPICs  on  the  PCB.  The  second  consists  of  a  single  antenna  connected  to 
the  other  modem  which  is  connected  to  another  dsPIC.  When  the  avionics  board  wants  to  send  a 
message  to  the  ground  station,  it  first  selects  an  antenna  to  communicate  with  (using  an 
algorithm  developed  by  the  ACS  subsystem  which  takes  into  account  distance,  attitude,  etc. . . 
and  chooses  the  best  antenna  to  use  for  communication).  Then  the  flight  computer  sends  packets 
to  the  modem  which  send  the  packet  to  the  ground  station.  At  the  ground  station,  the  signal  is 
received  using  a  3  meter  dish  and  then  the  packet  will  be  forwarded  to  the  MIT  station  via 
TCP/IP  where  the  packet  will  be  fully  decoded.  Communication  in  the  other  direction  works  the 
same  way.  Below  is  a  diagram  that  displays  the  CASTOR  to  MIT  ground  station  communication. 
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FIGURE  36:  OVERVIEW  OF  CASTOR  COMMUNICATION  LINK 


In  addition,  the  antennas  will  be  located  on  various  parts  of  the  CASTOR  body.  The  figure  below 
depicts  the  exact  positions  of  these  antennas,  represented  by  the  yellow  on  green  squares. 


2.4.3  BUDGET  (S.  PARRA) 

The  estimation  of  the  cost  of  the  communication  subsystem  has  been  done  breaking  the  system 
into  a  satellite  component,  and  into  a  ground  station  component.  The  first  is  related  to  the 
communication  hardware  elements  that  will  be  placed  on  the  satellite.  The  former  is  related  to 
the  hardware  elements  of  the  ground  station  plus  the  cost  of  upgrading  the  station  in  a  way  to 
make  it  suitable  for  CASTOR  mission. 


Component 

Part  number 

Company 

Quantity 

Price  per  unit 

Total  price 

Antennas 

Custom 

Custom 

3 

$33 

$99 

Straight  PCB 

R330-074 

RCA  Solutions 

3 

$3.30 

$9.90 
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Jack 

Modems 

MHX2420 

Microhard  Systems  Inc. 

Building  17,  2135-32 
Ave  NE 

Calgary,  Alberta  T2E 
6Z3 

2 

$800 

$1600 

MCX(M)  to 
SMA(F)-  9  inch 
cable 

202309SFB9 

RCA  Solutions 

2 

$13.28 

$26.56 

SMA(M)  to 
SMA(M)-  40 
inch  cable 

307303SFC40 

RCA  Solutions 

2 

$24.53 

$49.06 

SMA(M)  to 
SMA(M)-  50 
inch  cable 

307303SFC50 

RCA  Solutions 

1 

$27.80 

$27.80 

SMA(M)  to 
SMA(M)-  13 
inch  cable 

307303SFC13 

RCA  Solutions 

1 

$15.71 

$15.71 

Power  Splitter 

ZAPD-4-S+ 

Mini-Circuits 

1 

$64.95 

$64.95 

TOTAL 

$1892.98 

TABLE  2.4-2:  SATELLITE  COMM  BUDGET 


Component 

Part  number 

Company 

Quantity 

Price  per  unit 

Total  price 

Antenna 
(2.3m  dish) 

— 

Already  available  in 
Kwajalein 

1 

N/A 

N/A 

Modem 

MHX2420 

Microhard  Systems  Inc. 

Building  17,  2135-32 
Ave  NE 

Calgary,  Alberta  T2E 
6Z3 

1 

800$ 

800$ 

Cable 

N-female  to 
pigtail  cable 

L-com  Global 

Connectivity 

HyperLink  Wireless 
Division 

1201  Clint  Moore  Road 
Boca  Raton,  FL  33487, 
USA 

1 

25$ 

25$ 

Ground  station 
computer 

Already  available  in 
Cayenne 

1 

N/A 

N/A 

Operation 
computers  at 

MIT 

Generic 

computer 

Not  defined 

3 

~2k$ 

6k$ 

Personnel  at 

MIT 

Done  by  MIT  students 

3  people 

N/A 

N/A 

TOTAL 

$6825 

TABLE  2.4-3:  GROUND  STATION  COMM  BUDGET 
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2.4.4  LINK  BUDGET  AND  DATA  RATE  ANALYSIS  (M.  MUNOZ) 

The  final  link  budget  according  UNP  reviewers  suggestions,  and  under  the  assumption  of  using  the 
3m  antenna  is  shown  below: 


Color  Scheme 
Input  data 
Calculated  data 
Estimated  data 
Output  data 


Link  budget  at  115200bps 

Downlink  (6 
dB) 

Uplink  (35.3 
dB) 

R  (Data  rate  in  bps) 

115200.00 

115200.00 

P  (Tx  Power  in  dBW) 

0.00 

0.00 

Gt  (Tx  Antenna  Gain  in  dB) 

6.00 

35.30 

Gr  (Rx  Antenna  Gain  in  dB) 

35.30 

6.00 

B  (Rx  Noise  BW  in  Hz) 

83500000.00 

83500000.00 

Eb/NO  required  (dB) 

12.80 

12.80 

f  (Desired  Tx  Frequency  in  MHz) 

2442.00 

2442.00 

0aos  (Earth  Centric  Angle  @  AOS  in  rad) 

0.45 

0.45 

h  (Circular  Orbit  Altitude  in  km) 

700.00 

700.00 

Te  (Earth  noise  in  K) 

290.00 

290.00 

Gk  (Boltzmann's  const  in  dB) 

228.60 

228.60 

Lion  (Ionospheric  Loss  in  dB) 

-1.00 

-1.00 

Latmo  (H20  &  02  Losses  in  dB) 

-0.30 

-0.30 

Lrain 

-0.20 

-0.20 

Pointing  Loss  transmitter  (dB) 

-2.00 

-0.14 

Pointing  Loss  receiver  (dB) 

-0.14 

-2.00 

Demodulator  Loss  (dB) 

-1.40 

-1.40 

Tgal  (Galactic  noise  temp  in  K) 

50.00 

50.00 

Tant  (Total  Antenna  Noise  in  K) 

340.00 

340.00 
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Treceiver(k) 

290.00 

290.00 

Splitter  Loss  (dB) 

-3.00 

-3.00 

LI  (Line  Loss  in  dB) 

-0.77 

-0.77 

Raos  (Dist  to  SAT  @  AOS  in  km) 

3067.48 

3067.48 

Rmin  (Dist  to  SAT  @  Zenith  in  km) 

700.00 

700.00 

Ls-max  (Free  Space  Loss  @  AOS  in  dB) 

-169.94 

-169.94 

Ls-min  (  Free  Space  Loss  @  Zenith  in  dB) 

-157.11 

-157.11 

Ts  (Total  System  Noise  Temp  in  dBK) 

-27.99 

-27.99 

Lr  (Data  Rate  Loss  in  dBHz) 

-50.61 

-50.61 

Eb/No-aos  (Bit  Energy  to  Noise  Spec  Density  @  AOS  in 
dB) 

16.62 

16.62 

Eb/No-min  (Bit  Energy  to  NoiseSD  @  Zenith  in  dB) 

29.45 

29.45 

C/No-aos  (Carrier  to  NoiseSD  @  AOS  in  dB) 

67.23 

67.23 

C/No-min  (Carrier  to  NoiseSD  @  Zenith  in  dB) 

80.07 

80.07 

C/N-aos  (Carrier  to  Noise  at  Rx  @  AOS  in  dB) 

-11.98 

-11.98 

C/N-min  (Carrier  to  Noise  at  Rx  @  Zenith  in  dB) 

0.85 

0.85 

System  Margin  -aos(dB) 

3.82 

3.82 

System  Margin  -min(dB) 

16.65 

16.65 

TABLE  2.4-4:  LINK  BUDGET 


Both  the  downlink  and  the  uplink  have  the  same  energy  bit  to  noise  ratio  (Eb/No)  and  the  same 
system  margin.  This  is  because  the  communication  system  uses  of  the  same  type  of  modems  and 
data  rate  on  both  the  satellite  and  ground  station.  It  is  therefore  a  communication  system  with  a 
symmetric  link. 

Data  Rate  Analysis 

In  order  to  define  the  amount  of  images  that  the  communication  system  is  able  to  transmit  a  data  rate 
analysis  was  developed.  The  analysis  helped  determine  the  amount  of  pictures  that  could  be 
transmitted  using  a  data  rate  of  1 15.2  Kbps.  This  analysis  required  the  graphing  of  the  amount  of  data 
gathered  by  the  satellite  per  time,  and  the  amount  of  data  downloaded  per  time  when  the  satellite  was 
in  view  of  the  ground  station.  The  analysis  also  required  that  different  amounts  of  pictures  be  taken 
in  a  24  hour  period  to  test  the  capabilities  of  the  communications  system.  As  of  now,  the  propulsion 
team  would  like  to  take  a  picture  every  time  the  engine  fires.  Therefore,  in  consultation  with  the 
propulsion  team,  the  communications  team  has  set  the  picture  resolution  to  be  within  70-300  kpixels 
in  order  to  be  able  to  take  a  large  amount  of  pictures  per  day.  In  order  to  meet  this  requirement  it  is 
necessary  to  calculate  the  total  amount  of  data  collected  by  the  satellite  per  day  and  the  total  amount 
of  data  that  can  be  downloaded  from  the  satellite  per  day.  So  using  the  equation: 

Totalamountdownloaddbdata—totalamountofdataaoaimilated  =  dalalcfl  for  pictures 
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One  can  determine  how  many  downloadable  bits  are  left  for  pictures.  The  total  amount  of 
downloadable  data  is  calculated  by  multiplying  the  download  rate  (1 15.2  kbps)  by  the  total  amount 
of  communication  time.  It  was  determined  by  the  operations  team  that  the  total  amount  of  satellite 
subsystem  health  data  and  telemetry  rate  of  upload  would  be  67  bps;  if  the  packet  header  data  is 
included  the  total  data  rate  is  71  bps.  Therefore,  the  total  amount  of  data  accumulated  is  calculated 
by  multiplying  71  bps  by  86400  sec  (total  seconds  in  a  day).  Table  2.4-5shows  the  amount  of  data 
left  for  pictures  when  satellite  is  at  a  45  degree  inclination  (comm.  Time=  3045  sec)  and  when  it  is  at 

a  90  degree  inclination  (comm.  time=  870  sec). _ 

Data  available  per  day  (  45  degree  inclination) 

Comm.  time=  3045  sec 

Download  Rate  (kbps)  Amount  of  data  left  (Mbits) 

115.2  344.665 

Data  available  per  day  (  90  degree  inclination) 

Comm.  time=  870  sec 

Download  Rate  (kbps)  Amount  of  data  left  (Mbits) 

115.2  94.105 

TABLE  2.4-5:  DATA  AVAILABLE 
TABLE  2.4-6  AND 

Table  2.4-7 show  the  different  picture  resolutions  the  camera  that  will  be  mounted  on  the  satellite 
has.  Using  the  camera  resolution,  the  amount  of  bits  plus  its  packet  header  of  a  picture  can  be 
calculated.  This  information,  along  with  the  download  rates  and  the  communication  time  can  be 
used  to  calculate  how  many  pictures  per  day  can  be  taken  at  the  different  camera  resolutions.  The 
resolutions  highlighted  in  yellow  correspond  to  those  resolutions  that  match  the  10-200  kpixel 
requirement  of  the  propulsion  team.  The  amounts  of  pictures  that  can  be  taken  represent  ideal 
numbers,  therefore  the  rows  and  columns  in  green  show  a  40  percent  loss  in  the  number  of 
pictures  that  can  be  taken.  The  40  percent  was  chosen  by  the  communications  team  and  it 
represents  the  losses  of  pictures  to  due  loss  of  satellite  communication,  incorrect  data 
transmission,  etc. 


TABLE  2.4-6:  PICS  PER  DAY  (45  DEGREE  INCLINATION) 
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Pictures  per  day  (  90  degree  inclination)  comm,  time:  870  sec 

Assuming  40%  loss 

Download  Rate  (kbps) 

pixels 

kbits 

19.2 

115.2 

19.2 

115.2 

19.2 

115.2 

Res. 

Type 

VGA 

CIF 

SIF 

QCIF 

160*128 

80*64 

Pic. 

size 

kbits/(Pic.  + 
Fleader) 

#  of  pictures/day 

#  of  pictures/orbit 

#  of  pictures/day 

307200 

783.168 

13 

120 

0 

7 

7 

72 

101376 

258.445 

40 

364 

2 

22 

24 

218 

76800 

195.792 

54 

480 

3 

30 

32 

288 

38720 

98.711 

107 

953 

6 

59 

64 

571 

20480 

52.211 

202 

1802 

12 

112 

121 

1081 

5120 

13.052 

811 

7210 

50 

450 

486 

4326 

TABLE  2.4-7  PICS  PER  DAY  (90  DEGREE  INCLINATION) 


2.4.5  HARDWARE  (M.  MUNOZ) 

The  selection  of  the  antennas  has  been  revisited  with  respect  to  the  design  proposed  in  the  16.83 
class.  Our  past  choice  of  antennas  was  the  Hyperlink  Technologies  8  dBi  and  1  ldBi  2.4  GHz  patch 
antennas.  These  antennas,  designed  for  wireless  internet  broadcast,  were  designed  with  a 
hemispherical  radiation  pattern.  However  we  were  unsure  whether  these  antennas  could  withstand 
the  forces  they  would  experience  during  the  launching  phase  of  the  operation  because  of  their  flimsy 
construction.  We  decided  to  design  and  manufacture  our  own  antennas. 

The  type  of  antenna  we  decided  to  design  is  a  microstrip  patch  antenna.  This  type  of  antenna  is  a 
narrow  bandwidth,  wide-beam  antenna  fabricated  by  bonding  the  antenna  copper  element  to  an 
insulating  dielectric  substrate  with  a  continuous  metal  layer  bonded  to  the  opposite  side  of  the 
substrate  which  forms  a  ground  plane.  Our  microstrip  patch  antenna  would  be  edge  fed  and 
Figure  2.4-2  shows  a  basic  drawing  of  an  edge  fed  patch  antenna. 


h  J  dielectric  ( t ,) 


ground^/ 


FIGURE  2.4-2  MICROSTRIP  PATCH  ANTENNA 

The  necessary  measurements  to  make  an  antenna  with  a  center  frequency  of  2.442  GHz  can  be 
found  through  derived  equations. 
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THE  EQUATIONS  USED  TO  GET  THE  REQUIRED  DIMENSIONS  FOR  THE  RADIATING  COPPER 

ELEMENT  ARE  SHOWN  IN 

Figure  2.4-3.  Look  at  Figure  2.4-2  for  variable  reference. 

PATCH  GOVERNING  EQUATIONS 


CONSTANTS 


center  frequency  fr  —  2442 
X  =  0.1228  m 


speed  of  light  c  —  3.00  x  108  m/s 
dielectric  constant  sr  ~  4.2 
fmax  =  24835  MHz 
h  —  1.57  x  10~3m 


WIDTH  (w) 


w 


C  (£r  +  IV 

2fc\  2  J 


X 


/lOOOmmx 

V  lm  J 


LENGTH  (L) 

c 


L  = 


2/r -\/^e 


-  2A  l 


EFFECTIVE  DIELECTRIC  CONSTANT  (ee) 


er  +  1  er  —  1  (  12h\  2 

£»  —  — ^ - 1 - - —  I  1  H - 

w 


LINE  EXTENSION  (A l) 

hi  0.412(£e  +  0.3)  (^+  0.264) 
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FIGURE  2.4-3  PATCH  ANTENNA  EQUATIONS 

In  addition  to  the  radiating  copper  element,  the  feeding  microstrip  and  the  quarter  wave 
transformer  also  needed  to  be  designed.  Figure  2.4-4  shows  the  equations  used  to  calculate  the 
dimensions  of  the  microstrip  and  quarter  wave  transformer  so  that  there  is  matching  impedance 
across  all  the  antenna  elements. 
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MICROSTRIP  GOVERNING  EQUATIONS 
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FIGURE  2.4-4  MICROSTRIP/QUARTER  WAVE  EQUATIONS 


Table  2.4-8  shows  the  calculated  dimensions  for  the  antenna. 


TABLE  2.4-8  ANTENNA  DIMENSIONS 


Patch 

Microstrip  line 

Quarter-wave  transformer 

Length  (mm):  29.6094 

Length  (mm):  15.0 

Length  (mm):  15.0 

Width  (mm):  38.0942 

Width  (mm):  1.0934 

Width  (mm):  1.9554 

Char,  impedance  (ohms):  85.6764 

Char.  Impedance  (ohms):  85.6742 

Adapter  impedance  (ohms):  65.4501 

Efficiency:  61.72% 

Impedance  (ohms):  65.451 
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The  CASTOR  Communications  system  will  therefore  consist  of  three  of  these  custom  made 
antennas.  One  will  be  located  on  the  interior  of  the  left  hand  side  deployable  solar  panel.  Another 
antenna  will  be  located  on  the  top  of  the  satellite.  The  third  antenna  will  be  located  on  the  bottom 
of  the  satellite  opposite  to  the  top  antenna. 


Modem 

Our  choice  of  communications  band  has  been  based  on  flight  heritage  and  costs.  Since  the  high 
cost  of  a  Space  Qualified  Modem  was  prohibitive,  we  chose  the  MHX2420  S-band  transceiver 
mainly  due  to  the  flight  experience  on  Cubesat  missions.  This  modem  has  the  advantages  of  low 
power  consumption,  including  a  very  low  power  sleep  mode,  low  cost,  and  broad  thermal 
tolerances.  In  its  base  configuration,  this  modem  also  performs  frequency  hopping  in  order  to 
maintain  a  better  link  under  terrestrial  conditions;  the  issue  related  to  this  specific  modem 
characteristic  will  be  discussed  in  a  separate  section  of  this  document. 


MHX2420  Parameters  of  Interest 

Thermal  Tolerance 

-40  degrees  C  -  +85  degrees  C 

Input  Power 

4.0 -5.5  VDC 

Output  Power 

lOOmW  -  1W 

Maximum  Throughput 

230.4  kbps 

Dimensions 

89  mm  x  53.4  mm  x  17.8  mm 

Weight 

55  grams 

TABLE  2.4-9:  MHX2420  PARAMETERS  OF  INTEREST 


The  power  characteristics  of  a  test  MHX2420  modem  have  been  measured  in  the  lab  and  are 
shown  in  figure  2.4-15. 


Operational  State 

Measured  Power  Draw  (W) 

Command  mode  (no  TX  or  RX) 

1.62 

Data  transfer  mode,  sleep 

0  (power  draw  too  small  to  measure) 

Data  transfer  mode,  unconnected  idle 

2.13 

Data  transfer  mode,  connected  idle 

2.16 

Data  transfer  mode,  connected  data  transfer 

2.85-4.22 

Data  transfer  mode,  slave  waking  from  sleep 

1.59 

TABLE  2.4-10:  MEASURED  POWER  DRAWS 
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The  command  mode  of  the  MHX2420  allows  the  computer  access  to  the  modem’s  configuration 
registers,  suspending  all  modem  transmission  and  reception  in  the  meantime.  The  modem  can  be 
configured  to  enter  command  mode  automatically  on  startup  or  can  be  put  into  command  mode 
manually  by  entering  a  sequence  of  three  plus  signs  (“+++”). 

Data  transfer  mode  is  the  normal  operating  mode  of  the  modem.  In  the  chosen  network 
topology,  point-to-point,  one  modem  operates  as  “master”  and  one  as  “slave”.  The  modem 
onboard  the  spacecraft  will  be  designated  the  “slave”,  since  only  slaves  can  enter  the  very  low 
power  sleep  mode.  The  last  mode  in  the  table,  waking  from  sleep,  indicates  the  power  drawn 
when  a  slave  modem  wakes  up  and  checks  for  data  in  order  to  decide  whether  or  not  to  go  back 
to  sleep. 

When  data  is  being  transferred  between  the  two  modems,  one  modem  will  occasionally  buffer 
incoming  data,  resulting  in  power  spikes  during  the  transfer.  The  maximum  measured  peak  was 
4.22  W,  a  reasonable  value  given  the  required  1  W  of  RF  power  and  the  33%  average  efficiency 
of  amplifiers  in  the  2.4  GFIz  range. 

Connections  and  placements 

The  modems  will  connect  directly  to  the  dsPIC  over  two  RS232  connections.  All  connections 
outgoing  from  the  modem  are  at  TTL  voltage  levels,  hence  a  voltage  conversion  between  the 
modem  and  the  RS232  is  necessary.  These  connections  have  a  maximum  transfer  rate  of  1 15.2 
kbps,  the  tightest  restriction  on  our  maximum  communications  link  rate.  The  top  and  bottom 
antennas  will  connect  to  a  splitter  over  coaxial  cable  with  SMA  connectors.  The  splitter  will 
connect  to  one  of  the  modems  through  its  own  coaxial  cable  with  an  MCX  connector  terminating 
the  modem  end  and  an  SMA  connector  terminating  the  antenna.  The  Antenna  on  the  solar  panel 
will  connect  directly  to  the  2nd  modem  over  coaxial  cable  with  an  MCX  connector  terminating 
the  modem  end  and  an  SMA  connector  terminating  the  antenna. 

Both  modems  will  be  housed  in  the  avionics  stack  with  the  following  pins  connected.  Red 
indicates  PWR/GND  connections,  green  indicates  data  transfer,  and  blue  indicates  control  to 
UART1.  All  connections  outgoing  from  the  modem  are  at  TTL  voltage  levels.  These 
connections  have  a  maximum  transfer  rate  of  1 15.2  kbps,  the  tightest  restriction  on  our 
maximum  communications  link  rate. 

Both  modems  will  be  housed  in  the  avionics  stack  with  the  following  pins  connected.  Red 
indicates  PWR/GND  connections,  green  indicates  data  transfer,  and  blue  indicates  control 
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Vcc 

■  1 

40  □ 

NC 

VCC 

■  2 

30  P 

NC 

3.3V  or  bV  Select 

■  3 

30  □ 

NC 

VClccK 

□  4 

37  □ 

NC 

Shutdown 

□  S 

30  □ 

NC 

!Saalpgm_Mode 

□  3 

3i  o 

Diag  TxD 

USft_AN0 

□  7 

3 *  □ 

Diag  RxD 

!WAKEUP_usr 

□  3 

33  □ 

Rx^SVNC_LED 

!Config 

□  s  Ml  HX  35  □ 

TxMQDE_LED 

'Reset 

m  io 

31  □ 

RSSI3  LED 

V&b* 

□  ii 

30  □ 

RSSI2_LED 

Sleec  Mode 

□  12 

29  □ 

RS3I1_LED 

GND 

■  1.3 

20  □ 

CTS 

GND 

■  14 

27  O 

RTS 

GND 

■  15 

20  □ 

DSft 

GND 

111  16 

20  □ 

RING 

GND 

■  M 

24  □ 

DTP 

USft_l 

□  14 

23  □ 

TxD 

USft_2 

□  IS 

22  □ 

RxD 

U£R_3 

□  20 

21  □ 

UCD 

FIGURE  2.4-5:  MHX2420  CONNECTED  PIN  DIAGRAM 

The  pins  perform  the  following  functions: 


Pin  Mnemonic 

Function 

Vcc 

Provides  power 

Voltage  Select 

Selects  whether  modem  will  talk  on  3.3V  or 

5V 

!  Shutdown 

Active  low  input  shuts  down  modem 

!Bootpgm_Mode 

Active  low  input  downloads  firmware  to 
modem 

!WAKEUP_usr 

Active  low  input  wakes  up  modem 

IConfig 

Active  low  input  on  startup  puts  modem  into 
known  default  serial  configuration  (9600  baud, 
8/N/l,  no  flow  control) 

[Reset 

Active  low  input  resets  modem 

Sleep_Mode 

Output  pin,  active  high  indicates  modem  is  in 
sleep  mode 
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GND 

Ground 

RxD 

OUTPUT  pin.  Sends  data  received  over 
wireless  link  to  computer 

TxD 

INPUT  pin.  Receives  data  from  computer  to 
be  transmitted  over  wireless  link 

TABLE  2.4-11:  PIN  FUNCTIONS 


The  two  antennas,  as  previously  indicated,  will  be  bolted  to  the  long  edges  of  the  radiator  fins  in 
order  to  provide  signal  coverage  around  as  much  of  the  spacecraft  as  possible. 


2.4.6  SOFTWARE  AND  PROTOCOL  (S.  PARRA) 

The  CASTOR  software  protocol  follows  the  standard  7  layer  OSI  model  for  communication 
systems.  For  the  communication  system,  we  will  focus  on  the  bottom  4  layers  of  the  OSI  model, 
namely  the  physical,  data  link,  routing,  and  transport  layers. 


Transport 


Routing 


Data  Link 


Physical 


FIGURE  41:  PROTOCOL  STACK 

Physical/Data  Link/Routing  Layer 

The  physical  and  data  link  layer  of  the  CASTOR  communication  protocol  are  not  implemented 
by  the  team  at  MIT.  These  layers  are  implemented  through  the  transceiver  purchased.  They  use 
the  802.1  lg  standard  at  a  frequency  of  2.4GHz.  Other  standard  features  include  packet 
retransmission,  FEC  Coding  (Hamming/Reed  Solomon)  and  a  differential  binary  phase  shift 
keying  (DBPSK)  modulation  scheme.  For  data  encryption,  the  modems  selected  come  with  an 
added  feature  that  allows  data  to  be  encrypted  at  the  data  link  layer.  The  type  of  encryption  that 
this  modem  supports  is  128-AES.The  constraint  on  packet  size  (255  bytes)  comes  from  this  layer 
due  to  its  implementation  as  well  as  our  chosen  data  rate.  Since  CASTOR  is  only  communicating 
with  the  ground  station  via  point  to  point  link,  the  routing  layer  does  not  need  to  be  implemented. 

Link  Layer  Error  Detection 
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The  selected  modem  provides  guidelines  as  to  what  additions  it  makes  to  a  packet  on  the  link 
layer  before  it  is  transmitted.  In  short,  the  modem  allows  255  bytes  of  data  maximum  to  be 
included  in  one  packet.  The  modem  them  adds  its  own  preamble  and  CRC  to  this  body  of  data  to 
form  a  packet,  although  it  does  not  specify  the  format  or  size  of  this  additional  information. 


preamble 

header 

body 

CRC 

CRC 

I _ I  Modem  supplied 

I  1  CASTOR  supplied 

FIGURE  7:  MODEM  PACKET  STRUCTURE 

The  link  layer  is  transparent  to  upper  layers.  Therefore  with  this  modem  the  operation  defined 
by  the  protocol  can  be  carried  out  without  having  to  incorporate  how  to  explicitly  deal  with  the 
additions.  The  modem  can  also  request  to  have  a  packet  resent  based  on  the  link  layer  CRC.  If  a 
packet  fails  this  first  CRC,  the  modem  will  automatically  request  the  packet  before  it  ever  gets  to 
the  user-defined  CRC.  The  user  can  however  limit  the  number  of  retransmissions  that  are 
allowed. 

Transport  Layer 

The  bulk  of  the  transportation  protocol  comes  from  the  transport  layer.  This  is  fully  implemented 
by  the  MIT  team.  Below  are  specifics  of  the  transport  layer. 

Initializing  and  Terminating  Communication 

The  ground  station  will  communicate  with  CASTOR  whenever  CASTOR  is  within  range  of 
communication.  Refer  back  to  2.4.4  for  specifics  and  analysis  of  this  time  window.  The  ground 
station  will  continually  send  a  set  up  packet  and  CASTOR  will  receive  this  packet  as  a  start  of 
communication  i.e.  the  ground  station  will  always  initiate  communication.  Once  CASTOR 
receives  the  set-up  packet,  it  will  respond  with  a  series  of  set-up  packets  as  the  modem  requires 
four  packets  in  succession  to  determine  which  antenna  is  better  positioned  to  receive 
transmissions.  Once  CASTOR  has  decided  which  antenna  to  use,  it  will  begin  the 
communication  session. 

A  communication  session  between  CASTOR  and  the  ground  station  can  consist  of  a  sequence  of 
commands,  down  linked  images,  and  down  linked  telemetry.  Any  combinations  of  these  are 
acceptable.  At  the  end  of  communication,  the  ground  station  shall  send  CASTOR  an  end  packet 
and  with  an  ack  reception,  terminate  communication.  The  figure  below  shows  this  sequence, 
with  details  on  automatic  retransmission. 


COMMAND  SCENARIO 

Ground  Station  Satellite 
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Notes 

Sent  periodically  until  ACK  received 


ACK  Received,  send  normal  command 

WAIT  FOR  ACK:  If  no  ACK  received,  send 
normal  command  again 


normal  command  ACK  received,  may 
send  another  command 


send  TELEMETRY_BACKLOG  request 
packet 

STOP  AND  WAIT:  GS  waits  for  ACK 


ACK  Received,  send  take/get  image 
command 

STOP  AND  WAIT  FOR  ACK:  If  no  ACK 
received,  send  image  command  again 


Packet 


Packet 


SET  UP 


SET  UP  ACK 


Notes 

Sat  received  set  up,  acks  that  it  is  ready  to 
receive  commands 


Sat  sends  ACK  that  normal  command  is 

NORMAL  COMMAND  - ►  NORMAL  COMMAND  ACK  received 


NORMAL  COMMAND  - ►  NORMAL  COMMAND  ACK 


TELEMETRY  BACKLOG - ►  TELEMETRY  BACKLOG  ACK 


Sat  sends  ACK  that  it  will  now  start  sending 
specific  telemetry  down 


4 -  TELEMETRY_BACKLOG_l 

◄ -  TELEMETRY_BACKLOG_2 

.4 -  TELEMETRY_BACKLOG_3 

TE  LE  M  ETRY_BACKLOG_l  ACK 

TE  LE  M  ETRY_BACKLOG_2  ACK 
TELEMETRY_BACKLOG_3  ACK 
etc 


Sat  starts  sending  telemetry 


SELECTIVE  REPEAT  REQUEST:  After  all  ACK's  are 
receive,  retransmit  telemetry  that  was  not 
ACK'd 


IMAGE  - ►  IMAGE  ACK 


Sat  sends  ACK  that  it  will  now  transmit  image  to 
GS,  also  has  info  about  numPackets 


IMAGEJL  ACK 

_  IMAGEJL 

IMAGE  2  ACK 

IMAGF  ? 

IMAGE_3  ACK 

—  IMAGE_3 

etc 

etc 

send  image  packets,  IMAGE_1  will  contain 
number  of  total  packets  in  image 


SELECTIVE  REPEAT  REQUEST:  After  all  ACK's  are 
receive,  retransmit  telemetry  that  was  not 
ACK'd 


16.83  CASTOR  Design  Document 


Page  131 


November  18,  2010 


We  are  done  communicating,  send  END 
packet  END 

STOP  AND  WAIT  ARQ 


ENDACK 


Sat  sends  end  ACK  packet,  communication 
terminated 


FIGURE  8:  EXAMPLE  OF  A  TELEMETRY  COMM  LINK 


Packet  Definition 

CASTOR  and  the  ground  station  can  have  at  most  31  different  packet  types.  This  number  comes 
from  the  header  definition  (specified  later)  which  indicates  a  5  bit  memory  allocation  for  packet 
type.  As  of  now,  there  have  been  1 1  specified  packet  types,  specified  below. 


Type  of  Packet 

Description 

None 

Generic  packet 

Empty 

Generic  packet 

Set  up 

Initiating  communication 

Normal 

Various  commands  that  the  ground 

Command 

station  can  send  CASTOR 

Critical 

Time  critical  commands  yet  to  be 

Command 

specified 

Telemetry 

Backlog 

Used  for  down  linking  .csv  files  that 
contain  telemetry  logs 

Telemetry 

Current 

Sending  current  telemetry  readings 

Image 

Sending  images  to  ground 

Code  1  2 

Sending  new  code  to  PICs  1  and  2 

Code  3 

Sending  new  code  to  PIC  3 

Debug  Text 

Used  for  debugging  software 

TABLE  2.4-12:  PACKET  TYPES  WITH  DESCRIPTIONS 


The  type  of  packet  will  contain  information  based  on  what  command  shall  be  executed  on 
CASTOR.  On  top  of  this,  the  normal  command  packet  type  has  specific  command  type 
designators:  TYPE_ACTUATE,  TYPE_GETADC,  TYPE_PICDIRECT, 
TYPE_GET_MAGVALUE,  TYPE_GET_IMU,  TYPE_ACTIVATE_TORQUE_COILS, 
TYPE_GET_PICTURE,  TYPE_RE AD_MEMORY ,  TYPE_GET_TIME,  TYPE_SET_TIME, 
TYPE_HEATER,  and  TYPE_TELEMETRY_BACKLOG.  These  type  designators  specify  their 
respective  commands  in  CASTOR  software. 


Every  packet  consists  of  a  12  byte  header,  2  bytes  of  start  and  end  flags,  a  variable  amount  of 
user  data,  and  1  byte  of  error  detection.  Each  of  the  fields  is  discussed  in  further  detail  in  the 
following  sections. 

Header 
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The  header  for  every  packet  consists  of  12  bytes  of  identification  information.  The  breakdown 
of  the  header  is  summarized  below. 


Field 

Packet 

Origin 

Ack  Nack 

Needs  Ack 

Packet  Type 

Packet  Data 
Length 

Bits 

1 

1 

1 

5 

8 

Description 

O-CASTOR 

1-HETE 

0-ack 

1-nack 

0-no 

l-yes 

00000-None 
00001 -Empty 
00010-Set  up 
00011- 
Normal 
Command 
00100- 
Critical 

00101- 

Command 

00110-Tel. 

Backlog 

00111-Tel. 

Current 

01000-Image 

01001-Code 

1  2 

01010-Code 

3 

01011 -Debug 
Text 

Bytes  in  user  data 

TABLE  2.4-13:  PACKET  HEADERS 


ID 

Time  Sent 

Packet 

Count 

CRC 

8 

32 

24 

8 

Packet  ID 

Time  data 
collected 

Absolute 
count  of 
transmits 

Error 

Detection 

TABLE  2.4-14:  HEADER  DEFINITION 


The  Packet  Type  field  identifies  the  packet  as  one  of  the  1 1  types  of  packets.  Packets  can  then  be 
specified  as  a  type  of  acknowledgement  packet  via  the  ackNack  field.  The  Needs  Ack  field  is 
used  for  packets  that  must  be  acknowledged  by  the  receiver  to  proceed  with  communication.  The 
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3  byte  count  field  is  a  late  addition  that  can  be  used  for  a  variety  of  applications,  specified  by  the 
user.  Other  fields  of  the  packet  header  are  self  explanatory. 

User  Data 

The  functional  packets  vary  in  user  data  content,  which  is  summarized  in  Table  2. 4. 6-3. 


Functional  Packet 

Content 

Size 

Set-up 

Source  antenna 

1  byte 

Set-up  (empty) 

Source  antenna 

1  byte 

Set-up  (normal  command) 

Source  antenna,  command  code*, 
normal  command 

varies 

Set-up  (critical  command) 

Source  antenna,  command  code*, 
critical  command 

varies 

Telemetry  (empty) 

none 

N/A 

Telemetry  (backlog) 

State  and  System  Health  data** 

225  bytes 

Telemetry  (backlog  cutoff) 

State  and  System  Health  data** 

225  bytes 

Telemetry  (current) 

State  and  System  Health  data** 

225  bytes 

Command  (empty) 

none 

N/A 

Command  (normal  command) 

Command  code*,  normal  command 

varies 

Command  (critical  command) 

Command  code*,  critical  command 

varies 

TABLE  2.4-15:  FUNCTION  PACKET  CONFIGURATION 


*  Command  code  is  a  1  byte  identifier,  see  command  reference  list  in  Operations  Section 
**State  and  System  Health  data  defined  by  Orbits  and  Operations 

The  Set-up  packet  simply  indicates  from  which  antenna  the  packet  originated.  This  information 
will  be  useful  in  determining  CASTOR’s  orientation  and  the  functionality  of  the  two 
communication  systems.  The  Set-up  packets  also  contain  information  for  CASTOR  on  which 
antenna’s  packet  did  the  ground  station  hear  and  respond  to.  These  packets  however,  as  well  and 
the  Command  packets)  can  contain  commands  from  the  ground  station.  Each  command  is 
associated  with  an  identification  code.  All  the  identification  codes  are  known  to  CASTOR  and 
allow  it  to  know  the  size,  content,  and  organization  of  the  following  command.  A  normal 
command  packet  can  contain  up  to  25  normal  code  and  command  pairs.  A  critical  command 
packet  however  can  only  contain  one  critical  code  and  command.  This  restriction  is  necessary 
because  of  the  additional  steps  required  to  execute  a  critical  command.  Three  of  the  Telemetry 
packets  contain  the  Sate  and  System  Health  data  as  defined  by  the  Orbits  and  Operations  team. 
For  backlog  telemetry  reports,  this  data  will  have  been  collected  twice  a  minute  while  out  the 
ground  station’s  range.  For  the  current  telemetry,  the  data  will  be  collected  when  a  command  to 
do  so  is  received.  The  backlog  cutoff  Telemetry  packet  indicates  that  it  is  the  last  packet  in  the 
packets  to  be  sent,  although  not  the  last  packet  in  the  backlog  Telemetry.  Empty  telemetry 
packets  are  used  only  as  a  nack.  The  command  packets  function  just  as  the  Set-up  packets  do, 
without  the  source  antenna  information. 


ARQ  Protocol 
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The  CASTOR  Satellite  communication  protocol  must  be  able  to  detect  faulty  packets  and 
automatically  request  that  new  packets  be  sent.  Therefore,  the  communication  protocol  will 
support  an  ARQ  (automatic  repeat  request)  protocol  based  on  what  type  of  packet  is  being  sent. 
A  Stop  and  Wait  ARQ  shall  be  used  when  sending  any  type  of  normal  command  and  a  Selective 
Repeat  ARQ  shall  be  used  for  backlogged  telemetry  and  image  packets. 

In  a  Stop  and  Wait  ARQ  for  commands,  the  ground  station  sends  a  normal  command  to  the 
satellite  and  waits  to  receive  an  ACK  (acknowledgement)  packet  back  from  the  satellite  before 
issuing  another  command.  In  the  event  that  an  ACK  packet  is  not  received,  the  ground  station 
shall  automatically  resend  the  command  packet  after  a  timeout  window,  S,  which  must  be  equal 
to  or  greater  than  the  total  transit  time  of  the  packet  and  ACK  plus  any  time  for  processing.  A 
Stop  and  Wait  ARQ  is  the  best  choice  for  normal  commands  because  the  ground  station  must 
issue  commands  one  at  a  time  (each  command  is  also  only  one  packet)  to  CASTOR  with 
confirmation  that  CASTOR  has  received  that  command. 

A  Selective  Repeat  ARQ  works  well  for  CASTOR  when  sending  multiple  packets  to  the  ground 
station.  In  Selective  Repeat,  the  transmitter  (the  satellite)  sends  all  packets  in  a  row.  The  receiver 
(the  ground  station)  sends  an  ACK  packet  back  to  the  transmitter  for  each  packet  they  receive. 
After  all  packets  have  been  sent,  the  transmitter  selectively  and  automatically  resends  all  packets 
that  it  has  not  received  an  ACK  for.  This  works  well  for  backlogged  telemetry  and  images 
because  the  satellite  is  sending  hundreds  of  packets.  It  is  far  more  time  efficient  to  implement  a 
selective  repeat  and  automatically  retransmit  only  those  packets  that  have  not  been  ACK’d. 


Error  Detection 

The  Cyclic  Redundancy  Check,  or  CRC,  is  a  hash  code  designed  to  detect  unexpected  changes  in 
a  packet  body.  It  is  8  bits  long  and  generated  using  a  communications  engineering  industry 
standard  polynomial  equal  to  X8  +  X5  +  X4  +  X°  or,  written  in  binary,  1001 1001.  To  generate  the 
CRC,  the  data  stream  is  shifted  8  bits  to  the  left,  creating  8  zeros  at  the  end  of  the  data  stream. 
The  data  is  then  divided  by  the  polynomial.  In  binary,  this  division  is  equivalent  to  the  bitwise 
XOR  operation.  At  the  end,  the  remainder,  which  will  be  8  bits  long,  is  the  CRC. 

Due  to  data  packet  structure,  after  the  CRC  is  generated,  it  will  be  placed  at  the  end  of  the 
header.  The  received  data  must  be  verified  by  using  the  CRC.  On  the  receiving  end,  the 
communication  protocol  will  receive  a  packet,  generate  the  CRC  in  the  same  manner,  and  check 
to  see  that  the  CRC  that  was  just  generated  matches  the  CRC  associated  with  the  packet.  If  it 
matches,  then  the  data  packet  does  not  contain  errors.  If  not,  then  the  data  is  corrupted  and  the 
packet  must  be  retransmitted. 


Type  of  Packet 

Error 

Detection 

Response 

Set-Up 

lost 

Time  Out 

Send  again 

corrupt 

Fails  CRC 

Nack,  send  again 

TABLE  2.4-16:  SET-UP  PACKET  ERROR 
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Type  of  Packet 

Error 

Detection 

Response 

Set-Up 

lost 

Receive  Set-Up  again 

Send  again 

(empty) 

corrupt 

Fails  CRC 

Nack,  send  again 

Set-Up 

lost 

Receive  Set-Up  again 

Send  again 

(normal  command) 

corrupt 

Fails  CRC 

Nack,  send  again 

Set-Up 

lost 

Receive  Set-Up  again 

Send  again 

(critical  command  1) 

corrupt 

Fails  CRC 

Nack,  send  again 

Set-Up 

(critical  command  2) 

lost 

No  further  packets  after 
current  telemetry 

Send  again  after 
timeout 

corrupt 

Fails  CRC 

Nack,  send  again 

TABLE  2.4-17:  SET-UP  (GROUND  STATION)  ERRORS 


Type  of  Packet 

Error 

Detection 

Response 

Telemetry 

(empty) 

lost 

No  further  packets 
received 

Send  again  after 
timeout 

corrupt 

Fails  CRC 

Nack,  send  again 

Telemetry 

(backlog*) 

lost 

Skip  in  count,  cutoff 
comes  before  20 
packets 

Ignore  if  90% 
received,  resend 
chunk  otherwise 

corrupt 

Fails  CRC 

Nack,  send  again 

Telemetry 
(cutoff  backlog) 

lost 

No  further  packets 
received 

Send  again  after 
timeout 

corrupt 

Fails  CRC 

Nack,  send  again 

Telemetry 

(current) 

lost 

No  further  packets 
received 

Send  again  after 
timeout 

corrupt 

Fails  CRC 

Nack,  send  again 

TABLE  2.4-18:  TELEMETRY  PACKET  ERROR 


*  Continue  &  exit  designators  addressed  by  sequence  flag  header  field 


Type  of  Packet 

Error 

Detection 

Response 

Command 

(empty) 

lost 

No  further  packets 
received 

Send  again  after 
timeout 

corrupt 

Fails  CRC 

Nack,  send  again 

Command 
(normal  command*) 

lost 

No  further  packets 
received 

Send  again  after 
timeout 

corrupt 

Fails  CRC 

Nack,  send  again 

Command 

(critical  command  1*) 

lost 

No  further  packets 
received 

Send  again  after 
timeout 

corrupt 

Fails  CRC 

Nack,  send  again 

Command 

(critical  command  2*) 

lost 

No  further  packets  after 
current  telemetry 

Send  again  after 
timeout 

corrupt 

Fails  CRC 

Nack,  send  again 
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TABLE  2.4-19:  COMMAND  PACKET  ERRORS 
*  Continue  &  exit  designators  addressed  by  sequence  flag  header  field 


Encryption 

Based  on  UNP  recommendations,  it  has  become  necessary  to  add  encryption  to  data 
communication.  To  remedy  this  CASTOR  will  be  equipped  with  modems  that  support  simple 
AES- 128  encryption  built  in.  The  encryption  will  happen  at  the  data  link  layer  so  no  software 
implementation  needs  to  be  done  to  support  the  encryption. 


2.4.7  GROUND  STATION  (M.  MUNOZ) 

The  HETE  (High  Energy  Transient  Explorer)  network  was  constructed  by  a  university 
consortium  led  by  MIT’s  Kavli  Institute  in  order  to  communicate  with  the  HETE  satellite  in 
Earth  orbit.  However,  since  the  HETE  satellite  went  silent  in  2007,  the  network  has  not  been 
carrying  traffic.  We  have  negotiated  with  the  Kavli  Institute  for  use  of  this  network. 

The  HETE  network  consists  of  three  ground  stations  located  in  Cayenne,  Singapore,  and 
Kwajalein.  Since  our  system  requires  a  frequency  allocation  license  from  the  FCC  (refer  to 
section  2.4.8  for  more  information  on  licensing),  we  will  only  be  able  to  use  the  Kwajalein 
station.  The  Kwajalein  ground  station  is  equipped  with  a  1.8m  dish,  an  MHX2420  modem,  and  a 
computer. 

The  scheme  of  the  ground  station  is  showed  in  Figure  2.4-9: 
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FIGURE  2.4-9:  GROUND  STATION  BLOCK  DIAGRAM 


The  1.8m  dish  is  old;  hence  some  work  will  be  required  to  upgrade  the  whole  system.  We  will 
need  to  test  the  functionality  of  the  dish,  to  connect  it  with  our  modem,  and  to  upgrade  the 
pointing  and  tracking  system.  The  estimation  of  the  cost  for  these  upgrades  is  still  to  be  defined, 
as  well  as  when  these  upgrades  will  be  implemented. 

In  case  we  are  unable  to  obtain  a  license  from  the  FCC  or  if  something  were  to  go  wrong  with 
the  Kwajalein  station,  the  CASTOR  team  is  currently  looking  to  alternative  ground  stations  as 
backup  solutions. 

One  backup  solution  being  considered  is  using  the  GENSO  ground  stations.  GENSO  is  a 
worldwide  network  of  ground  stations  which  can  interact  via  a  software  standard  and  therefore 
dramatically  increase  the  level  of  access  to  orbital  satellites  which  in  turn  increases  the  return 
from  educational  space  missions  and  the  opportunities  for  sending  commands  to  the  spacecraft 
and  receiving  telemetry  from  it. 
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2.4.8  LICENSING  (M.  MUNOZ) 

In  order  to  be  able  to  communicate  successfully  under  FCC  regulations,  the  communication 
system  of  the  CASTOR  satellite  needs  a  license  that  will  allow  us  to  transmit  and  receive  data  at 
the  system  frequency  of  2.442  GHz. 

The  types  of  licenses  we  had  could  have  chosen  from  for  CASTOR  are  from  the  following: 

-experimental  licenses:  easy  to  be  obtained,  maximum  amount  of  communication  time  of  two 
years.  The  system  does  not  have  to  cause  interference,  and  it  has  to  be  able  to  be  turned  off  if  it  is 
requested; 

-amateur  licenses:  they  have  fewer  constraints  in  the  power  and  in  the  interference.  The  process 
is  longer,  but  this  type  of  license  guarantees  the  allocation  of  a  band  as  primary  user.  Also  in  this 
case,  the  system  has  to  be  designed  in  a  way  to  be  easily  turned  off,  if  requested. 

Given  the  possibility  of  using  the  communication  channel  as  primary  users,  the  Amateur  Radio 
License  option  seems  to  be  the  most  appealing.  Unfortunately,  the  fact  that  the  flight  modems  are 
equipped  with  FHSS  and  a  standard  data  encryption  code  makes  it  difficult  for  us  to  apply  for 
this  license.  In  addition  to  the  data  encryption  the  modems  will  have,  they  are  also  equipped  with 
FHSS  which  is  a  form  of  spread  spectrum  technique  that  can  be  seen  also  as  a  sort  of  encryption 
and  this  is  against  the  scope  of  amateur  radio  services.  It  is  maybe  possible  to  obtain  a  waiver, 
but  to  be  sure  to  obtain  a  license  the  team  decided  to  apply  for  an  experimental  license. 

The  application  for  the  experimental  license  was  submitted  on  Oct.  07,  2010.  This  is  our  third 
attempt  at  obtaining  a  license  from  the  FCC  and  unlike  the  second  time  where  the  provided 
coordinates  located  the  Kwajalein  ground  station  in  the  middle  of  the  ocean,  we  were  able  to 
provide  all  the  correct  information  to  complete  the  application  process.  Currently  we  are  in 
dialogue  with  the  FCC  in  order  to  provide  them  some  more  details  that  they  have  requested 
relating  to  the  ground  station.  If  no  more  issues  arise,  we  should  have  an  approved  license  in 
about  4  weeks. 


2.4.9  FHSS  (M.  MUNOZ) 

The  issue  of  FHSS  (Frequency  Hopping  Spread  Spectrum  technique)  is  emerged  during  the  UNP 
PDR,  where  the  reviewers  have  expressed  some  concerns  about  the  FHSS  scheme  currently 
implemented  in  our  modem.  An  analysis  has  been  conducted  to  decide: 

•  If  CASTOR  should  use  the  FHSS  or  not. 

•  What  are  the  conditions  for  the  correct  functioning  of  the  FHSS  for  space  application? 

The  final  decision  concerning  FHSS  is  that  CASTOR  will  keep  the  modems  equipped  with 
FHSS  and  that  it  will  use  a  data  rate  of  1 15.2kbps  in  order  to  have  the  modems  operating 
correctly. 

The  final  decision  has  been  taken  on  the  base  of  different  parameters: 
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1)  Flight  heritage:  the  current  modems  equipped  with  FHSS  have  already  been  used  in 
Cubesat  missions  successfully  (example:  MAST  mission).  Additionally,  we  don't  have 
any  data  about  the  same  type  of  modems  without  the  FHSS.  Hence,  nobody  can 
guarantee  that  the  elimination  of  the  FHSS  in  this  type  of  modem  will  affect  it  in  a  way 
that  it  will  not  be  able  to  operate  correctly  in  space.  There  is  no  apparent  reason  for  which 
this  can  happen,  but  we  simply  don't  have  any  flight  heritage  of  MHX2420  without 
FHSS  to  be  able  to  confirm  that  this  system  will  work. 

2)  Expert  opinions:  in  order  to  deal  with  FHSS  issue  two  communication  experts  at  MIT 
have  been  contacted:  Muriel  Medard  and  Vincent  Chan.  They  both  have  suggested  to 
keep  the  modems  with  FHSS  since: 

>  FHSS  is  a  good  way  to  counteract  interferences  that  are  strong  in  the  2.4GHz 
band; 

>  FHSS  is  already  implemented  in  the  modems  , hence  the  elimination  of  the  FHSS 
will  bring  the  modem  to  work  in  a  suboptimal  condition  with  poor  results  in  terms 
of  communication; 

>  Using  long  hopping  intervals  the  problem  of  mismatch  due  to  propagation  delay 
will  be  considerably  reduced; 

>  Using  a  communication  rate  high  enough  with  respect  to  the  Doppler  shift,  the 
frequency  shifting  problem  will  be  considerably  reduced. 

3)  UNP  other  teams:  four  of  the  eleven  UNP  teams  are  equipped  with  our  same  modems. 
Hence,  they  have  been  contacted  to  understand  how  they  are  dealing  with  this  issue.  The 
result  is  that  they  don't  have  at  the  moment  solved  this  issue.  They  are  thinking  about 
this,  but  probably  they  will  keep  the  modems  as  they  are. 

4)  Microhard  experts:  Microhard  engineers  have  been  contacted  to  analyze  the  possibility  of 
changing  the  settings  of  the  modems.  The  result  is  that  they  can  eliminate  the  FHSS,  but 
there  is  no  guarantee  about  the  behavior  of  the  system.  According  to  their  experience, 
they  know  that  modems  equipped  with  FHSS  are  currently  working  in  space.  These 
transmitters  are  working  fine  if  they  are  used  at  a  data  rate  greater  than  115.2kbps.  This  is 
due  to  the  Doppler  shift  and  to  the  fact  that  the  receiver  needs  to  have  a  band  large 
enough  to  identify  the  shifting  of  the  signal  in  order  to  detect  it  correctly. 

In  conclusion,  the  analysis  has  determined  that  the  final  configuration  for  the  CASTOR 
modems  will  be: 

1)  MODEMS  equipped  with  FHSS; 

2)  DATA  RATE  of  115.2kbps; 

3)  HOPPING  INTERVAL  of  150ms  (maximum  available). 


2.4.10  RISK  ANALYSIS  (S.  PARRA) 

Risk  is  a  serious  concern  to  the  CASTOR  Communication  Subsystem.  The  communication 
system  must  function  at  all  times  due  to  the  sensitivity  of  the  data  stream.  One  huge  risk 
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mitigation  factor  that  we  have  implemented  is  full  modem/antenna  redundancy.  Our  risk  matrix 
is  below  with  analysis  on  a  risk  level  associated  with  each  risk  mitigation  factor. 


Risk  Description 

Mitigation 

Severity 

Likelihood 

Risk 

Level 

If  the  new  patch  antenna  configuration  is  used, 
before  deployment  there  will  only  be  one 
operational  antenna  on  the  outside  hence  there  will 
be  no  redundancy.  Still  can  communicate,  but  less 
oppurtunity  to  communicate 

A  possible  solution  is  to  put  a  6dBi 
antenna  on  the  outside  however  this 
would  require  a  switch  between  the 

2  antennas.  A  3dB  loss  would  be 
incurred  but  the  link  budget  would 
remain  fine. 

3 

0 

low 

System  is  set  up  to  switch  between  antennas 
depending  on  which  one  provides  a  better 
communications  link. 

There  is  no  way  to  overcome  the 
failure  of  the  switching  mechanism, 
however  it  is  safer  than  having  no 
switch  and  no  second  antenna  to 
solve  the  previous  risk 

3 

3 

MED 

There  could  be  interference  on  the  communications 
subsystem  due  to  other  components  of  the  satellite. 

An  EMI  test  will  be  performed  to 
model  and  characterize  the 
interference  due  to  other 
components. 

unknown 

1 

unknown 

Plastic  cover  of  antenna  might  be  damaged  in  space 
which  could  make  the  antenna  inside  perform  sub 
optimally. 

Testing  will  be  done  at  MIT  Lincoln 
Lab  on  the  antennas  without  their 
plastic  covers  to  analyze  their 
performance 

1 

1 

low 

Plastic  cover  of  antenna  might  be  damaged  in  space 
which  could  make  the  antenna  inside  perform  sub 
optimally. 

Testing  will  be  done  at  MIT  Lincoln 
Lab  on  the  antennas  without  their 
plastic  covers  to  analyze  their 
performance 

1 

1 

low 

A  connection  between  antenna,  modem,  or  a  PIC 
could  fail. 

Need  to  verify  that  the  different 
connections  between  antennas, 
modems,  and  PICs  are  all  strong  and 
in  a  position  where  the  connection 
cannot  be  lost. 

3 

1 

low 

Modem  could  be  short-circuited. 

Need  to  ensure  that  the  board 
where  the  modem  will  be  placed  on 
is  properly  designed  to  avoid  such 
possibilities. 

3 

2 

MED 

Both  Modems  could  be  short-circuited. 

careful  manufacturing  &  testing 

4 

2 

MED 

TABLE  2.4-20:  COMM  RISK  ANALYSIS 


2.4.11  MULTI- ANTENNA  SWITCHING  ALGORITHM  (M.  MUNOZ) 


The  satellite  is  equipped  with  three  antennas  as  a  mitigation  strategy  for  antenna  failure  and  as  a 
means  to  communicate  with  the  ground  station  at  a  larger  range  of  attitude  orientations  than  is 
available  for  a  single  antenna.  Furthermore,  the  communication  system  will  include  an  algorithm 
for  switching  between  antennas  while  the  satellite  is  in  the  deployed  and  controlled  state.  Even 
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though  the  final  location  of  the  antennas  has  been  chosen,  the  algorithm  to  determine  which 
antenna  should  be  used  to  communicate  with  the  ground  station  can  be  updated  with  antenna 
locations  on  the  satellite  body  with  little  effect  on  the  algorithm  process. 

The  switching  process  is  a  function  of  the  satellite  attitude,  the  location  of  the  ground  station,  and 
the  location  of  the  antennas  on  the  satellite.  At  each  time  step  of  the  switching  algorithm,  the 
direction  cosine  matrix  relating  the  body  axis  of  the  satellite  to  the  inertial  reference  frame  is 
used  to  rotate  the  position  of  each  antenna  from  the  satellite’s  body  axis  to  the  Earth  centered 
reference  frame.  Each  of  these  vectors  is  then  added  to  the  vector  from  the  ground  station  to  the 
center  of  the  satellite.  The  two  resulting  sums  are  the  vectors  from  the  ground  station  to  each  of 
the  antennas.  The  magnitude  of  each  of  these  vectors  can  be  compared  to  determine  which 
antenna  is  closed  to  the  ground  station,  and  therefore  is  not  blocked  by  the  body  of  the  satellite. 
The  below  figure  depicts  the  algorithm  process. 


Ant  1 


— ►  J 

Ground  Station 


FIGURE  2.4-10:  ANTENNA  SWITCHING  PROCESS 

The  vector  p  is  the  vector  from  the  ground  station  to  the  satellite  in  the  inertial  frame.  It  is 
calculated  by  subtracting  the  position  vector  of  the  ground  station  from  the  position  vector  of  the 
satellite  in  the  inertial  frame.  The  vector  from  Ant  1  and  Ant  2  is  rotated  into  the  inertial  frame 
using  the  direction  cosine  matrix,  which  is  updated  by  the  ADCS  system  at  each  cycle  in  the 
ADCS  control  period.  The  switching  control  period  will  be  at  a  lower  frequency  than  the  ADCS 
control  period,  so  an  up  to  date  direction  cosine  matrix  will  always  be  available.  The  sum  of  the 
vector  p  and  the  Ant  1  and  Ant  2  vectors  gives  the  vectors  Rant  ±  and  Rant  2  respectively. 
Whichever  of  these  vectors  has  a  lesser  magnitude  will  correspond  to  the  antenna  unobstructed 
by  the  body  of  the  satellite,  in  this  example  Ant  1. 

This  algorithm  must  be  combined  with  orbital  propagation  information  provided  by  the  GNC 
system  in  order  to  determine  when  the  Earth  is  not  obstructing  the  view  of  the  ground  station  by 
the  antennas.  This  information  can  be  found  by  transforming  the  vector  from  the  ground  station 
to  the  satellite  (represented  above  by  p)  into  an  azimuth,  elevation,  and  range  as  seen  from  the 
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ground  station  reference  frame  using  a  known  series  of  transformation  rotations.  If  the  elevation 
is  above  an  acceptable  range  (usually  10  degrees)  the  satellite  is  within  line  of  sight  of  the 
ground  station  and  can  communicate  using  the  antenna  that  is  unobstructed  by  the  body  of  the 
satellite. 

The  algorithm  is  fairly  robust  to  angular  rates  on  the  satellite  body.  According  to  Matlab 
simulation  of  the  attitude  of  the  satellite  with  applied  control  and  disturbance  torques,  the 
antenna  switching  algorithm  could  have  a  frequency  as  low  as  0.1  Hz  or  one  cycle  per  ten 
seconds  and  will  calculate  approximately  95%  of  the  antenna  switches  required  to  maximize 
communication  opportunities.  Furthermore,  the  algorithm  is  robust  to  position  error  because  the 
same  position  vector  is  added  to  both  antenna  vectors  in  order  to  calculate  the  distance  between 
each  antenna  and  the  ground  station.  If  the  position  vector  has  error,  it  will  be  the  same  for  both 
calculations. 

When  the  satellite  is  in  a  tumbling  state,  the  algorithm  will  be  turned  off  and  instead  all 
modems/antennas  will  be  turned  on  and  allowed  to  transmit.  The  purpose  of  this  is  to  provide 
better  coverage  during  the  period  when  the  satellite’s  orientation  can’t  be  controlled.  The 
communications  team  believes  that  during  tumbling  mode,  the  switching  algorithm  will  not  be 
able  to  effectively  change  between  antennas  especially  if  the  satellite  has  a  high  rotation  rate. 
Consultation  with  the  power  team  is  still  necessary  at  this  point  in  order  to  determine  if  they  can 
provide  us  the  necessary  power  (about  8  watts)  to  have  both  modems  3  antennas  working  at  the 
same  time. 

Lastly,  when  the  satellite  is  in  the  stowed  configuration,  the  algorithm  will  also  be  turned  off  and 
only  the  top  and  bottom  patch  antennas  will  be  functioning.  This  is  because  the  solar  panels 
when  in  the  stowed  configuration  block  the  interior  patch  antenna  and  dramatically  reduce  its 
ability  to  transmit  and  receive  data  and  commands. 


2.4.12  COMMUNICATION  TESTING  (M.  MUNOZ,  S.  PARRA) 


FlatSat  Testing 

The  purpose  of  the  FlatSat  test  is  threefold.  First  of  all,  we  want  to  test  system  hardware  by 
simulating  a  complete  packet  transmission  from  the  ground  station  to  the  satellite.  This  includes 
modems,  avionics  hardware,  antennas,  and  PCB/proto-board  setups.  Secondly,  we  want  to  ensure 
that  the  communication  protocol  and  software  is  functioning  as  expected.  This  also  includes 
hardware/software  integration.  Fastly,  this  test  is  helpful  for  new  communications  subsystem 
members  to  get  familiar  with  the  CASTOR  communication  subsystem,  the  FlatSat  testing 
environment,  and  the  communication  subsystem  hardware  and  software  layout. 

The  simulated  ground  station/satellite  setup  shall  be  as  closely  related  to  that  described  in  the 
Communication  Subsystem  Overview  (2.4.2)  as  possible.  For  FlatSat  testing,  we  will 
demonstrate  the  capability  to  communicate  a  command  packet  to  the  satellite  and  visibly  view 
the  command  being  interpreted  by  watching  a  linear  actuator  physically  move.  The  MIT  ground 
station  GUI  has  capabilities  to  initiate  communication.  The  user  specifies  FlatSat/ Actuator  test 
and  inputs  2  arguments.  Input  1  describes  which  actuator  to  use,  in  this  specific  case,  the 
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command  is  for  the  Linear  Actuator,  so  a  1  is  inputted.  Input  2  describes  the  percentage 
extension  the  user  was  the  actuator  to  move.  For  power  and  reliability  reasons,  this  number 
should  be  an  element  of  (0,100)  exclusive. 

The  successful  demonstration  of  the  test  shows  that  the  communication  system  is  integrated  with 
avionics  and  that  our  hardware  and  software  is  correctly  functioning.  Below  are  further 
scheduled  tests  and  their  status. 


Type  of  Test 

Description 

Status 

Linear  Actuator 

Show  that  the  ground  station  can 
send  a  linear  actuator  command  to 
CASTOR 

Code  complete,  test 
verified 

CRC 

Show  that  the  CRC  is  fully 
implemented  and  properly 
functioning 

Code  complete,  test 
verified 

Magnetometer 

Sensing 

Show  that  we  can  correctly  read  data 
from  the  magnetometer 

Code  complete,  test 
verified 

Temperature 

Sensor 

Show  that  we  can  accurately  read 
temperature  data 

Code  complete,  test 
verified 

Camera  Imaging 

Show  that  the  camera  is  fully 
integrated  and  CASTOR  is  able  to 
send  camera  images  to  the  Ground 
Station. 

Code  complete,  test 
verified 

Automatic  Repeat 
Requests 

Show  that  functionality  exists  for 
losing  packets  for  files  requiring 
segmentation 

Code  complete,  test 
verified 

ARQ  Protocol  Testing 


Overall  Goal  and  Objective:  To  demonstrate  functionality  of  the  ARQ  protocol  for  image 
retransmission.  Based  on  requirements,  the  communication  protocol  must  be  able  to 
automatically  detect  packet  errors  and  be  able  to  automatically  request  new  packets  be  sent.  The 
automatic  repeat  request  for  images  and  telemetry  shall  work  by  using  the  ground  station  to 
detect  failed  packets  and  automatically  send  a  single  packet  to  the  satellite  requesting  failed 
packets  be  resent. 

Setup:  The  test  shall  occur  at  the  avionics  and  communications  bench  in  the  SSL  using  the 
flatsat  format.  After  complete  implementation  of  software  support,  we  shall  simulate  an  image 
command  followed  by  downlink  of  that  image.  The  ground  station  shall  then  purposefully  lose 
some  packets  which  will  then  result  in  a  check  list  for  failed  packets  to  populate  on  the  ground 
station.  Once  the  entire  image  has  been  downlinked  to  ground,  the  ground  station  shall  then 
automatically  send  a  request  for  those  specific  packets  to  be  resent  back  to  ground. 

Expected  Results:  Since  we  are  specifying  what  specific  packets  will  be  lost,  we  expect  the 
retransmit  list  to  be  populated  with  the  exact  packets  specified  on  the  ground  station.  We  then 
expect  this  message  to  be  received  on  the  satellite  followed  by  an  acknowledgement  back  to 
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ground,  as  all  commands  to  the  satellite  shall  be  acknowledged  by  the  satellite.  After  this,  the 
satellite  should  read  the  image  specified  by  an  image  id  off  the  SD  card  and  retransmit  lost 
packets  back  to  the  ground  station. 

Actual  Results:  Screen  shot  below  of  flatsat  testing 


FIGURE  1 1 :  FLATSAT  TESTING  SCREENSHOT 


The  GUI  above  depicts  ground  station  operations.  The  left  side  of  the  figure  shows  this  ground 
station  GUI  while  the  right  figure  shows  the  “under  the  hood”  operations  of  the  ground  station, 
displaying  technical  data  such  as  hexadecimal  packet  interpretations  and  any  print  statements 
made  through  the  C  code.  We  can  see  that  this  test  was  successful  by  analyzing  the  packet  flow 
from  the  screen. 

On  the  right,  we  notice  that  the  ground  station  has  finished  receiving  packet  data,  and  will  now 
send  retransmission  data  to  the  satellite  (top  red  circle).  Further  below,  the  packet  has  been  sent 
to  the  satellite  with  the  requested  information,  and  we  notice  that  the  data  sent  contains  two 
packets,  packet  number  22  and  packet  number  87.  It  is  important  to  note  that  these  two  numbers 
show  incremental  values  based  on  C  arrays,  meaning  that  the  first  packet  is  labeled  packet  0. 
When  actual  data  is  being  sent  back  to  the  ground  station,  these  numbers  become  incremented  by 
one  to  show  that  packet  numbers  begin  with  packet  1,  as  shown  on  the  ground  station  GUI. 

The  GUI  shows  packets  being  sent  to  the  ground  station  from  the  satellite.  We  see  that  the 
ground  station  received  all  packets  from  the  satellite.  Then,  the  retransmit  data  is  automatically 
sent  and  we  receive  an  acknowledgement  packet  showing  that  that  retransmit  data  command  has 
been  received.  The  satellite  now  sends  the  image  packets  again  corresponding  to  the  correct 
image  id  and  the  correct  packet  numbers. 
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The  test  shows  that  we  have  successfully  sent  an  automatic  repeat  request  to  the  satellite,  and  the 
satellite  has  resent  the  specified  packets  without  any  prompt  from  the  user. 


Antenna  Testing 

In  order  to  determine  how  well  the  custom  patch  antenna  will  perform  on  the  satellite,  it  is 
necessary  to  test  their  functionality.  The  communication  team  wrote  a  comprehensive  test  plan 
that  seeks  to  determine  the  gain  and  radiation  pattern  of  the  patch  antenna.  This  test  will  consist 
of  three  different  test  scenarios.  The  first  test  will  consist  of  testing  the  patch  antenna  isolated 
from  the  satellite  structure.  The  2nd  test  will  consist  of  the  patch  antenna  installed  on  the  interior 
of  one  of  the  deployable  solar  panels.  The  other  test  scenario  will  consist  of  the  patch  antenna 
located  near  the  thruster  and  in  the  same  axial  direction  as  the  thruster.  The  last  two  tests  are 
geared  towards  determining  the  effects  the  satellite  structure  has  on  antenna  performance.  The 
first  test  will  be  done  on  Nov.  23  at  the  MIT  Lincoln  Lab.  The  test  will  be  performed  in  the 
tapered  chamber  found  at  the  lab.  First  the  antenna  under  test  (AUT)  is  set  on  some  sort  of 
rotator  at  the  "box"  end  of  the  chamber.  The  transmit  signal  is  launched  from  the  tip  of  the 
"cone"  end,  and  is  basically  guided  to  the  AUT  by  the  wedge  absorber  lining  the  cone.  The  AUT 
receives  the  transmitted  signal.  Any  energy  "splattered"  off  the  mechanical  portions  of  the  test 
setup  (non-receiving  portions  of  antenna,  the  mount,  the  pedestal,  etc.)  is  attenuated  by  the 
pyramidal  absorber  lining  the  box  end.  The  signal  received  by  the  AUT  is  converted  to  a 
frequency  through  a  mixer,  and  the  level  is  recorded  by  the  receiver.  This  will  be  done  for  every 
1  degree  angle  for  which  the  antenna  was  rotated  for  a  total  of  360  degrees.  Furthermore,  the  test 
will  run  for  10  frequencies  between  2.4  and  2.5  GHz.  The  Frequency  step  will  be  .01  GHz. 

In  addition,  the  8dBi  patch  antennas  that  were  previously  going  to  be  used  in  the  design  will  also 
be  tested.  They  recently  underwent  vibration  testing  so  we  want  to  verify  that  their  gain  and 
radiation  pattern  were  unaffected  by  the  vibration  tests.  If  these  antennas  still  function  adequately 
we  will  consider  them  as  a  viable  alternative  in  case  the  custom  antennas  do  not  work. 

Splitter  Testing 

The  Power  splitter  is  connected  to  the  modem  and  to  two  of  the  custom  antennas.  Its  purpose  is 
to  split  the  transmission  power  into  two  parts,  one  part  for  each  antenna.  We  need  to  test  the 
splitter  to  make  sure  that  it  is  functioning  correctly.  We  plan  on  testing  the  splitter  by  connecting 
it  to  a  vector  network  analyzer  and  measuring  the  S-parameters  of  the  splitter.  The  port 
connected  to  the  modem  is  called  port  1  and  the  other  ports  connected  to  antenna  1  and  2  are 
called  port2  and  3  respectively.  In  order  to  determine  that  the  splitter  is  functioning  correctly,  the 
S 1 1  measurement  should  be  a  large  negative  decibel  value.  Ports  2  and  3  should  see  a  3  dB  loss 
when  signal  is  passed  through  them.  In  other  words,  the  S12  and  S13  parameters  should  see  a  3 
dB  power  loss  from  the  input  signal.  Any  deviation  from  the  expected  measurements  described 
above  signifies  the  splitter  is  not  functioning. 
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2.4.13  CONCLUSION  AND  FUTURE  WORK  (S.  PARRA) 

The  current  CASTOR  Communication  Subsystem  nearly  meets  all  requirements  as  outlined  in 
2.4.1.  We  have  successfully  demonstrated  the  capability  of  data  transmission  from  the  ground 
station  to  the  satellite  through  the  FlatSat  testing  environment  in  the  SSL.  However,  more  work 
still  needs  to  be  done  with  regards  to  specific  packet  transmissions,  command  interpretation,  and 
satellite  telemetry.  The  timeframe  for  these  tasks  varies  from  the  end  of  the  fall  term  to  the  end 
of  the  spring  term.  On  the  hardware  side,  further  antenna  design  and  testing  needs  to  be  done. 
Licensing  is  near  completion  and  needs  to  be  finalized.  Furthermore,  along  with  software 
implementation,  hardware  integration,  and  testing,  work  needs  to  be  done  on  finalizing  ground 
station  operations. 
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2.5  PROPULSION 


2.5.1  INTRODUCTION  (J.  PARHAM) 

For  the  mechanical  design  section,  the  hardware,  testing,  and  technical  analysis  for  the 
propulsion  system  will  be  detailed.  Additionally,  mission  operations  and  their  requirements  for 
the  propulsion  system  will  be  covered.  It  includes  a  general  overview  of  the  system  and  details 
on  thruster  efficiency  testing,  operational  procedure.  It  also  follows  up  with  future  work  and 
analysis  to  be  completed  as  pertains  to  the  NASA  Xenon  gas  feed  system  and  the  plumbing 
system  of  the  Castor  satellite  that  will  be  finalized  and  tested  in  the  coming  months. 


2.5.2  OVERVIEW  (K.  LOEBNER) 

The  propulsion  system  onboard  CASTOR  will  use  electric  propulsion  to  propel  the  small 
satellite.  The  system  consists  of  the  xenon  propellant  feed  system,  associated  plumbing  and 
pressure  vessel,  and  the  Diverging  Cusped  Field  Thruster  (DCFT).  Using  the  DCFT  as  its 
primary  propulsion  system,  CASTOR  must  operate  throughout  the  mission  lifetime  of  1500 
hours.  Hence,  the  propulsion  system  must  likewise  be  operable  for  the  same  amount  of  time  so 
that  on-orbit  performance,  efficiency,  and  degradation  of  the  DCFT  can  be  measured  and 
compared  to  thrusters  of  similar  technologies  and  power  levels.  Those  metrics  will  be  measured 
on-orbit  by  tracking  the  state  of  the  spacecraft  and  thruster  during  the  mission.  Data  on  the 
orbital  path  of  CASTOR  after  repeated  firings  will  allow  performance  and  efficiency  to  be 
determined,  and  the  rate  of  degradation  will  be  measured  using  the  change  in  those  metrics.  The 
duties  of  the  Propulsion  team  are  to  design  a  system  to  properly  deliver  xenon  to  the  thruster,  to 
determine  the  operating  point  for  the  DCFT  that  will  permit  optimal  performance  while  ensuring 
maximally  efficient  use  of  xenon  propellant,  as  well  as  perform  all  integration  tests  necessary  to 
ensure  all  components  perform  as  expected  in  their  final  configurations. 


TABLE  2.5-1:  PROPULSION  BUDGET 


Component 

Mass 

Nominal  Power 

Cost 

DCFT 

1.20  kg 

88  W 

$3500 

Xenon  Tank 

2.95  kg 

N/A 

$836 

Cathode 

1.10  kg 

(Included  in  DCFT) 

$6000 

Plumbing 

5.064  kg 

1  W 

$1498 

Xenon  Gas  (Fuel) 

5.90  kg 

N/A 

$29,500 

Total 

16.214  kg 

101  W 

$41,334 
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2.5.3  RELEVENT  SYSTEM  REQUIREMENTS 

1.  The  propulsion  system  shall  be  able  to  operate  for  1500  hours  as  stated  in  mission 
requirements 

2.  The  thruster/cathode  system  shall  be  fully  insulated  electrically  from  the  rest  of  the 
system 

3.  The  thruster/cathode  system  shall  be  far  enough  from  other  systems  so  they  are  not 
damaged  by  the  thruster,  (this  requires  that  the  plume  emitted  by  the  thruster  does  not 
contact  any  surface.  The  plume  shape  will  be  determined  through  testing.) 


2.5.4  DIVERGING  CUSPED  FIELD  THRUSTER 


ANALYSIS 

The  thruster  used  on  the  CASTOR  satellite  is  the  Diverging  Cusped  Field  Thruster.  The  thruster 
is  based  on  a  design  by  D.  Courtney.  It  was  built  in-house  and  requires  a  minimum  of  40W  to 
provide  approximately  5mN  of  thrust  to  the  satellite  when  operating.  The  engine  functions  using 
the  principle  of  electrostatic  ion  propulsion,  in  which  an  electrically  charged  plasma  is 
accelerated  by  an  electromagnetic  field.  The  plasma  in  this  case  is  made  from  Xenon  ions,  and 
the  electric  potential  is  created  across  the  anode  and  cathode  while  a  cusped  magnetic  field  is 
created  by  a  set  of  three  permanent  magnets  in  the  thruster  cone.  Xenon  is  ionized  in  the  cathode, 
and  the  resulting  free  electrons  flow  towards  the  anode  and  are  caught  in  the  magnetic  field. 
Neutral  Xenon  atoms  are  pumped  from  the  anode  and  then  ionized  by  the  trapped  electrons,  and 
the  resulting  Xenon  ions  are  accelerated  by  the  electric  field  out  of  the  thruster  cone,  producing 
thrust.  The  thruster  itself  consists  of  two  main  components:  the  BHC-1500  hollow  cathode  and 
the  thruster  cone,  which  contains  the  anode. 

While  in  sunlight,  the  DCFT  will  be  provided  88  W  to  produce  an  expected  thrust  of  5.3  mN  at 
an  Isp  of  about  700s  and  an  efficiency  of  25%.  These  numbers  are  tentative  and  will  be  solidified 
after  efficiency  testing  and  analysis  has  been  performed.  During  eclipse,  Xenon  flow  to  the 
anode  and  cathode  will  be  shut  off.  The  power  to  the  anode  will  be  turned  off  as  well,  and  to 
prevent  the  need  for  cathode  reconditioning  when  re-entering  the  sunlight  period,  36  W  will  be 
supplied  to  the  engine’s  heater  to  keep  the  cathode  hot  and  allow  for  a  rapid  restart  upon 
reentering  sunlight. 
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FIGURE  2.5-1:  SOLIDWORKS  DESIGN  OF  THRUSTER 


Rocket  Propulsion  Elements,  7th  Edition  (Sutton  and  Biblarz,  Chapter  19)  contains  the  necessary 
equations  to  determine  the  properties  of  the  thruster  based  on  our  chosen  AV.  Relevant  equations 
for  electric  propulsion  are: 


m0 


C  hp9 

mp  _  (m0-mf) 
ma  m0 

p  _  IsyT9 
2*17 

F  —  ma  Eq.  5 

Av  —  at  Eq.  6 


Eq.  1 
Eq.  2 
Eq.  3 
Eq.  4 
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Where  Av  is  the  difference  in  velocity  of  the  two  circular  orbits  and  gives  the  change  in  velocity 
necessary  for  an  electric  propulsion  spiral  transfer  orbit. 

mt  is  the  final  mass  of  the  system 

rrio  is  the  initial  mass  of  the  system 

mp  is  the  mass  of  the  propellant 

c  is  the  effective  exhaust  velocity 

P  is  the  power  required 

Isp  is  the  specific  impulse  of  the  thruster 

T  is  the  thrust  produced 

g  is  the  gravitational  constant  for  the  earth 

i]  is  the  propulsive  efficiency 

1500  hours  of  firing  time  will  achieve  an  approximate  velocity  change  of  lOOOm/s  and  will 
require  5.9kg  of  99.999%  purity  Xenon  to  fuel  the  thruster. 


2.5.5  TESTING 


Operational  testing,  as  well  as  preliminary  integrated  power  system  testing,  has  been  performed 
on  the  thruster.  Both  tests  were  successful  and  provided  valuable  information  about  the  operation 
of  the  engine.  Future  testing  will  focus  on  the  characterization  of  the  engine  using  a  thrust 
balance.  Engine  performance  will  be  measured  for  the  power  ranges  of  40-300W  and  the  flow 
rate  ranges  of  4-12  standard  cubic  centimeters  per  minute.  The  thrust  balance  will  measure  the 
thrust,  from  which  the  Isp  and  efficiency  can  be  determined.  Plots  graphing  efficiency,  Isp,  thrust, 
power,  and  flow  rate  against  each  other  will  be  created  from  this  testing,  and  the  results  will 
determine  the  maximum  efficiency  of  the  DCFT. 

THRUST  BALANCE  CALIBRATION 

Prior  to  performing  the  DCFT  efficiency  testing,  the  thrust  balance  must  be  calibrated. 
Calibration  is  required  to  form  a  relationship  between  the  output  of  the  thrust  balance  and  the 
actual  thrust  produced.  The  thrust  balance  uses  voice  coils  placed  at  the  bottom  stand  of  the 
thrust  balance  to  measure  the  amount  of  thrust  produced  by  the  engine.  When  the  DCFT 
produces  thrust,  the  voice  coils  produce  an  opposite  and  equal  force,  keeping  the  thrust  balance 
in  equilibrium.  The  voltage  required  to  produce  the  requisite  restoring  force  is  measured  using  a 
specially  designed  FabView  program,  and  then  converted  into  a  force  using  the  data  obtained 
during  calibration.  This  resultant  force  is  the  thrust  value. 
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DCFT  EFFICIENCY  TESTING  PROCEDURE 


Cathode  Conditioning 

The  DCFT’s  cathode  must  be  conditioned  to  cleanse  the  engine  of  any  debris  or  contamination 
prior  to  firing. 

1.  Connect  PPU  to  power  supply 
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2.  Connect  PPU  to  anode  and  cathode  of  engine 

3.  Turn  on  power  supply 

4.  Turn  cathode  heater  on  to  2A  @  2V  for  90  min  (4W)  with  PPU 

5.  Increase  heater  amperage  to  4A  @  4V  for  90  min  (16W)  with  PPU 

6.  Increase  heater  amperage  to  6A  @  6V  for  60  min  (36W)  with  PPU 

7.  Increase  heater  amperage  to  6.5V  @  7V  for  30  min  (45. 5W)  with  PPU 

8.  Turn  on  keeper  with  PPU 
DCFT  Efficiency  Testing  Procedure 

1.  Perform  cathode  conditioning 

2.  Ignite  thruster 

3.  Set  Xenon  flow  rate 

4.  Incrementally  adjust  power  between  40  and  300W,  taking  thrust  measurements  at  each 
increment 

5.  Increment  flow  rate 

6.  Perform  another  power  sweep  between  40  and  300W,  once  again  taking  thrust 
measurements  at  each  increment 

7.  Repeat  process  until  all  flow  rates  between  4  and  12  seem  have  been  tested 
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FIGURE  2.5-3:  ENGINE  TESTING 


After  data  at  each  power  level  and  each  flow  rate  has  been  collected,  analysis  will  begin. 
Analysis  will  be  done  using  a  spreadsheet  specifically  designed  to  calculate  the  efficiency  of  the 
thruster  at  different  power  levels  and  different  flow  rates  given  the  data  output  by  the  data 
collection  software  written  using  LabView.  The  important  values  on  the  spreadsheet  include  the 
power,  flow  rate,  and  thrust,  and  by  inserting  different  values  for  power  and  flow  rate,  we  can 
determine  an  efficiency  level.  The  main  equation  is: 

F2 

77  =  - 

2Pm 

q  is  efficiency 
F  is  thrust 
P  is  power 
777  is  fuel  mass  flow 

Using  the  force  produced  by  the  thruster  (calculated  using  the  thrust  balance),  the  power  put  into 
the  thruster,  and  the  fuel  mass  flow  rate  set,  the  efficiency  of  the  DCFT  can  be  determined. 
Because  sets  of  data  at  different  combinations  of  power  levels  and  fuel  mass  flow  rates,  a  plot  of 
efficiency  at  various  levels  can  be  plotted,  and  the  maximum  efficiency  of  the  thruster  can  be 
determined. 
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2.5.6  CATHODE 


ANALYSIS 

The  cathode  used  for  the  thruster  is  the  BHC-1500  Hollow  Cathode,  manufactured  by  Busek. 
This  is  the  same  cathode  that  has  been  used  during  testing.  This  cathode  has  also  been  flown  in 
space  and  has  proven  its  functionality  on  orbit.  The  cathode  costs  approximately  $6000  and  will 
be  purchased  as  a  single  unit.  It  will  be  mounted  to  the  thruster  mounting  plate  at  a  distance  from 
the  thruster  to  be  determined  from  characterization  testing.  There  is  little  risk  with  the  use  of  this 
cathode  as  it  will  be  purchased  off  the  shelf  and  has  been  proven  to  operate  with  the  DCFT. 

RISKS 

There  are  significant  risks  if  the  cathode  is  improperly  used.  The  cathode  is  a  fragile  piece  of 
equipment  and  can  be  easily  contaminated  if  conditioned  or  operated  incorrectly.  It  is  imperative 
that  the  operation  procedures  detailed  in  Section  1.1.10.4  are  followed  without  deviation. 


2.5.7  TANK,  XENON,  AND  PLUMBING  SYSTEM  (K.  CHOU) 

RELEVANT  SYSTEM  REQUIREMENTS 

1.  The  plumbing  system  shall  safely  transfer  Xenon  gas  from  the  tank  to  the  thruster. 

2.  There  shall  be  a  procedure  for  cleaning  the  plumbing  system  prior  to  launch  so  that  there 
is  no  contamination  with  the  Xenon. 

3.  The  plumbing  system  shall  have  safety  valves  to  prevent  a  pressure  build-up  capable  of 
bursting  the  system 


PLUMBING  SYSTEM  DESIGN,  ANALYSIS,  AND  COST 

The  plumbing  system  will  transfer  Xenon  gas  from  the  tank  to  the  anode  and  cathode  while 
CASTOR  is  in  the  sunlight  portion  of  its  mission.  A  schematic  of  the  plumbing  system  is 
shown  below  in  Figure  2.5-4.  The  system  consists  of  the  tank,  a  pressure  regulator,  and 
multiple  safety  valves  to  ensure  proper  operation. 
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Relief  Valve 
relieves 
pressure  if 
it  exceeds 
6000  psi 


Pressure  Regulator  reduces 
pressure  to  10-20  psi 


Xenon 
at  4500 
psi 


Pilling  Procedure 


Manual  Valve  allows  us  to  fill  our 
tank  with  Xenon  without  any 
losses  incurred  by  connecting  the 
tank  to  the  feed  system. 


Flow  Controller  must  regulate 
Cathode  flow  to  1  seem  to 
function  at  full  capacity. 


* 


- ► 

Flow  Controller  must  regulate 
Anode  flow  to  6-10  seem  to 
function  at  full  capacity. 


FIGURE  2.5-4:  PLUMBING  SYSTEM  CONFIGURATION 


A  fill  valve  (not  pictured)  will  be  used  to  fill  the  tank  with  Xenon.  Prior  to  launch,  it  will 
also  be  used  to  decontaminate  the  plumbing  system  of  any  air  by  flushing  air  out  of  the 
system  with  a  cheap,  nonreactive  gas,  such  as  Argon.  The  plumbing  system  components 
on  the  low-pressure  side  and  to  the  left  of  the  solenoid  valves  will  be  decontaminated 
during  the  heating  process  necessary  for  cathode  conditioning.  The  Xenon  on  the  high- 
pressure  side  will  be  at  1800psi.  A  pressure  relief  valve  set  at  6000psi  is  also  located  on 
the  high-pressure  side  and  will  be  used  to  bleed  out  excess  pressure  to  prevent  the  tank 
or  plumbing  system  from  bursting.  Once  the  system’s  pressure  is  within  operable 
conditions,  the  relief  valve  will  reseal  so  that  Xenon  is  not  drained  into  space 
unnecessarily.  The  GO  pressure  regulator  will  reduce  the  pressure  to  about  15psi,  the 
operational  pressure  on  the  low-pressure  side,  and  the  flow  controller  will  reduce  the 
flow  to  the  proper  flow  rate  for  the  cathode  and  anode.  The  cathode’s  flow  rate  will  be 
one  standard  cubic  centimeter  per  minute  (seem).  We  are  currently  looking  into 
decreasing  the  flow  rate  to  the  cathode,  which  would  increase  the  DCFT’s  efficiency,  as 
can  be  seen  by  the  equation: 


F2 

V  ~  2  Pm 
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r|  is  efficiency 
F  is  thrust 
P  is  power 
m  is  fuel  mass  flow 

The  flow  rate  to  the  anode  is  expected  to  be  in  the  range  of  4  seem  to  12  seem,  based  on 
previous  testing.  The  piping  for  the  plumbing  system  will  be  1/8”  and  1/4"  stainless  steel 
tubing.  The  estimated  cost  and  mass  of  the  plumbing  system  are  $1833.34  and  4.51kg 
respectively.  Table  2.5-2  breaks  down  the  plumbing  system  into  its  individual 
components,  including  the  tank 


TABLE  2.5-2:  PLUMBING  SYSTEM  COMPONENT  LIST 


PART 

COMPANY 

PRODUCT 

MASS  [kg] 

COST  [USD] 

Tank 

Luxfor 

L45J 

2.95 

350 

Stainless  Tube 

McMaster 

SS316  Tube 

0.1 

23.84 

Pressure  Regulator 

GO  Regulator 

CPR-1 

0.5 

280 

Solenoid  Valves 

ASCO 

AL1124LOS 

0.038 

50 

Relief  Valve 

Swagelok 

SS-4R3A 

0.216 

144.50 

Flow  Control 

Omega 

FMA3204ST 

0.2 

935 

Manuel  Valve 

McMaster 

7833K95 

0.51 

50 

TANK  AND  TANK  ADAPTER 

The  cylindrical  tank  will  hold  5.2kg  of  Xenon  to  achieve  mission  requirements,  although  it  is 
capable  of  holding  up  to  7.7kg.  The  tank  costs  $350,  has  a  mass  of  2.95kg,  and  has  dimensions 
of  46.8cm  in  length  and  13.9cm  in  diameter.  The  cost  of  Xenon  is  $5000  per  kilogram,  and  the 
company  from  whom  we  purchase  the  Xenon  will  also  perform  the  tank  filling  procedure. 

The  current  plumbing  system  connection  to  the  tank  consists  of  two  individual  pieces:  a  mating 
adapter  and  a  tubing  connector.  To  create  a  simpler  and  more  reliable  configuration,  a  solid  part 
was  deemed  necessary. 
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FIGURE  2.5-4:  PREVIOUS  TANK  CONNECTOR  ASSEMBLY 


The  initial  design  (see  Figure  2.5-4)  was  built  from  off-the-shelf  Swagelok  connectors.  The  main 
piece  was  a  stainless  steel  1/16”  duct  that  threaded  into  a  1/4"  fitting,  which  funneled  gas  from 
the  tank  to  the  tubing  system.  The  second  piece  was  an  adapter  that  fit  the  1/2"  tank  opening  to 
the  main  piece.  These  two  pieces  tightened  together,  protruding  1  1/4"  from  the  mouth  of  the 
tank,  and  expelled  gas  axially. 

The  profile  of  the  assembly  was  constrained  by  the  way  the  tubing  could  connect  the  flow 
between  the  tank  and  piping  because  the  tubing  had  to  be  routed  so  that  the  flow  could  exit 
normally  to  the  plane  of  the  assembly  orifice.  Another  problem  with  the  initial  design  was  that 
there  was  an  extra  seal,  or  point  of  failure,  between  the  two  pieces. 

To  remedy  the  problems  presented,  the  pieces  were  merged  into  one  part,  preserving  the 
functionality  of  the  original  assembly.  As  seen  in  Figure  2.5-5,  the  projection  of  the  tank  adapter 
is  now  less  than  one  inch,  and  the  tubing  is  redirected  at  a  90°  from  the  axial  direction.  The  new 
design  introduces  the  ability  to  turn  the  flow  off  sooner  without  any  bent  tubing  or  adapters.  A 
feature  that  carried  over  to  the  new  design  includes  the  hexagonal  molds  for  ease  of  tightening. 
Also,  the  small  diffuser  at  the  exit  of  the  tank  adapter  prevents  instabilities  from  forming  in  a 
sudden  expansion  to  the  tubing  size. 
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SECTION  A-A 


.500 


FIGURE  2.5-5:  CUSTOM  TANK  ADAPTER 


2.5.8  OPERATIONAL  PROCEDURE  (T.  HERY) 


THRUSTER  OPERATING  POINT 

The  thruster  depends  on  several  variables  to  determine  its  thrust,  efficiency,  and  Isp.  From  these 
characteristics,  the  amount  of  Xenon  required,  flight  time,  and  power  required  from  the  solar 
panels  and  batteries  can  be  calculated.  Although  many  of  the  thruster’s  characteristics,  such  as 
thrust  for  a  specific  power  input,  have  not  been  tested  in  the  vacuum  chamber  yet,  the  following 
is  the  Propulsion  team’s  best  estimate  of  the  engine  operating  point. 


The  driving  factor  in  determining  the  thruster  operating  point  is  available  power.  According  to 
UNP  requirements,  the  volume  of  the  satellite  is  limited  to  a  50  x  50  x  60  cm  box,  which  limits 
the  size  of  the  solar  arrays.  With  the  current  design,  the  satellite  will  have  0.278  m  of  solar  cell 
area,  which  can  generate  up  to  165  W  of  power.  After  including  inefficiencies  in  the  EPS  system, 
100  W  will  be  delivered  to  the  PPU,  which  powers  the  cathode  keeper  and  the  anode. 
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SUNLIGHT 

The  operation  of  the  DCFT  during  eclipse  will  provide  thrust  to  the  CASTOR  satellite.  It  is 
expected  that  10  W  will  be  provided  to  the  PPU  during  sunlight,  which  will  deliver  88  W  to  the 
thruster  to  produce  an  expected  6.1  mN  of  thrust  at  an  Isp  of  about  920  s  and  an  efficiency  of 
27%.  These  numbers  are  based  on  previous  performed  tests  and  are  expected  to  improve  with 
thruster  optimization.  Due  to  the  solar  panels  being  fixed  on  the  body,  there  will  be  some  times 
during  sunlight  when  the  engine  will  not  be  able  to  fire.  This  will  be  considered  part  of  eclipse 
operations. 

ECLIPSE 

During  eclipse  (and  the  non-firing  portions  of  sunlight)  the  Xenon  flow  to  the  anode  and  cathode 
will  be  shut  off.  The  power  to  the  anode  will  be  shut  off  and  the  cathode  will  go  into  a  heating 
state  using  the  heater.  The  keeper  will  be  shut  off  and  36  W  will  be  delivered  to  the  heater  so 
that  the  cathode  remains  hot  and  is  ready  for  a  quick  start  the  next  time  the  satellite  enters 
sunlight. 


ALTERNATIVE  OPERATING  POINTS 

The  motivation  for  keeping  the  engine  hot  during  eclipse  derives  from  engine  fatigue.  Both  the 
anode  and  cathode  have  parts  that  will  degrade  with  time,  and  the  degradation  is  accelerated  by 
the  voltage  and  current  spikes  associated  with  starts  and  stops,  as  well  as  heat  cycling  associated 
with  cooling  and  reheating  the  thruster  cone  and  cathode.  To  keep  the  cathode  hot,  the  heater  will 
be  run  on  battery  power  during  eclipse. 


The  current  design  uses  36  W  during  eclipse  to  keep  the  cathode  hot.  There  is  a  possibility  that 
the  keeper  can  be  left  on  instead  of  the  heater  during  eclipse  which  requires  only  12  W  as 
opposed  to  36  W.  There  is  also  the  possibility  of  using  the  heater  at  a  lower  power.  Both  of  these 
options  will  be  investigated  during  the  thruster  efficiency  testing. 


These  two  alternative  points  for  eclipse  operation  first  need  to  be  tested  before  they  are 
considered  viable  options.  Using  the  keeper  during  eclipse  requires  using  Xenon  which  reduces 
the  overall  mission  Isp  or  requires  additional  Xenon  mass.  The  lower  power  heater  operation 
may  damage  the  cathode  due  to  thermal  cycling.  Requiring  less  power  during  eclipse  is 
considered  a  priority  and  will  be  tested  as  soon  as  possible. 


NORMAL  THRUSTING  CYCLE 

This  process  describes  the  steps  taken  in  the  lab  to  start  the  thruster  from  a  cold  initial  sate.  By 
heating  the  thruster  during  eclipse,  the  first  two  heating  steps  are  not  needed  in  a  typical  orbit. 
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1.  Turn  heater  on  to  3.5  A  @  3.5  V  for  15  min  (12.25  W). 

2.  Increase  heater  current  to  7.0  A  @  7  V  for  15  min  (49  W). 

3.  Turn  cathode  keeper  on.  The  converter  should  automatically  go  to  0.5  A  @  24  V 
(12  W). 

4.  After  5  min,  reduce  the  current  to  the  cathode  heater  to  0  A  in  30-second  steps  of 
2A. 

5.  Then  turn  anode  converter  on.  The  voltage  should  go  straight  to  200  V  @  0.5-1  A 
(120  W). 

6.  Keep  the  cathode  keeper  and  anode  converter  on,  and  the  thruster  should  provide 
thrust. 

7.  To  shut  down,  turn  cathode  keeper  and  anode  converter  off. 


CATHODE  CONDITIONING 

Cathode  conditioning  is  a  one-time  event  that  must  take  place  right  after  launch,  to  cleanse  the 
cathode  of  any  debris  or  contamination. 

1.  Turn  cathode  heater  on  to  2  A  @  2  V  for  90  min  (4  W). 

2.  Increase  heater  amperage  to  4  A  @  4  V  for  90  min  (16  W). 

3.  Increase  heater  amperage  to  6  A  @  6  V  for  60  min  (36  W). 

4.  Increase  heater  amperage  to  6.5  A  @  7  V  for  30  min  (45.5  W). 


Note:  All  cathode  heater  voltages  are  based  on  experimental  results. 


LEO  requires  a  special  conditioning  procedure  because  the  orbital  period  is  only  90  minutes, 
with  a  typical  eclipse  of  around  36  minutes.  To  complete  the  cathode  conditioning  in  LEO, 
power  from  the  solar  panels  will  heat  the  cathode  while  in  sunlight  and  stored  power  from  the 
batteries  will  heat  the  cathode  in  eclipse.  This  way,  the  conditioning  will  not  be  interrupted  by 
eclipse. 


PLUMBING  OPERATION 
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DECONTAMINATION 

The  main  risks  associated  with  the  plumbing  system  are  inadequate  decontamination  and 
procedures  before  launch  and  leaking  during  the  mission.  Decontamination  will  occur  before  the 
filling  of  the  tank  from  the  high  pressure  side  to  the  solenoid  valves  and  will  occur  on  orbit  for 
the  low  pressure  side  after  the  solenoid  valves.  Decontamination  requires  creating  a  vacuum 
from  the  tank  to  the  solenoid  valves  (while  the  first  is  closed  and  the  second  opened)  and  then 
pumping  Xenon  into  the  system  until  the  desired  fuel  mass  is  reached.  Once  on  orbit,  both 
solenoid  valves  will  be  opened  and  1  seem  of  Xenon  will  flow  through  the  system  for  30  minutes 
before  the  conditioning  procedure  begins. 

NORMAL  OPERATION 

During  normal  operation,  the  majority  of  the  plumbing  system  components  are  mechanically  set 
and  do  not  require  inputs  to  operate.  The  exceptions  are  the  solenoid  valves  and  flow  controllers. 
The  1st  solenoid  valve  will  remain  closed  from  launch  until  decontamination  and  will  remain 
open  during  the  sunlight  portions  of  the  mission  and  closed  during  the  eclipse  portions.  The 
second  solenoid  valve  will  remain  open  until  decontamination.  It  will  close  during 
decontamination  and  conditioning  and  then  will  remain  open  for  the  remainder  of  the  mission. 
The  flow  controllers  will  operate  only  when  the  thruster  is  firing  (as  well  as  conditioning  for  the 
cathode  flow  controller).  They  will  be  shut  off  during  eclipse. 

2.6  POWER 


2.6.1  OVERVIEW  (M.  HABIB) 

The  Power  System  is  responsible  for  producing  and  storing  power  for  the  CASTOR  bus  and 
DCFT.  An  array  consisting  of  four  solar  panels  will  capture  solar  energy  and  using  a  Maximum 
Power  Point  Tracker  (MPPT)  a  maximum  power  of  165.1  W  will  be  produced  in  the  sunlight.  20 
Nickel  Cadmium  (NiCd)  batteries  will  be  responsible  for  storing  energy  on  the  spacecraft  to  be 
used  for  powering  the  satellite  during  all  eclipse.  Voltage  converters  will  be  used  to  convert  the 
voltage  from  the  bus  voltage  to  specific  voltages  required  by  components. 

Nickel  Cadmium  Batteries 

CASTOR  will  use  20  Nickel  Cadmium  (NiCd)  [1]  battery  cells  connected  in  series.  The  batteries 
are  required  to  power  all  the  necessary  sub-systems  for  CASTOR  as  well  as  the  Cathode  keeper 
during  eclipse.  The  NiCd  battery  cells  are  rated  for  4. 5 Ah  with  a  nominal  voltage  of  1.2V.  20 
cells  are  used  to  create  a  bus  voltage  of  24V  for  the  satellite.  This  leads  to  a  total  battery  mass  of 
2.64kg. 

Battery  Box 

In  compliance  with  UNP-6  guidelines,  the  battery  cells  are  contained  in  an  aluminum  box  [2]  in 
a  7-6-7  egg  crate  configuration.  The  battery  box  is  necessary  to  protect  the  battery  cells,  contain 
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any  electrolyte  leakage  (if  it  occurs  in  flight  which  is  highly  unlikely),  and  regulate  the 
temperature  of  the  battery  cells  both  by  insulating  them  and  providing  a  radioactive  surface. 

MPPT 

A  Maximum  Power  Point  Tracker  (MPPT)  [3]  is  used  to  maximize  the  amount  of  power 
absorbed  by  the  solar  cells  and  to  distribute  the  power  to  both  the  battery  and  the  satellite  loads. 
The  MPPT  used  by  CASTOR  is  the  SunSaver  MPPT  designed  by  Momingstar  Corporation.  The 
output  voltage  of  the  MPPT  is  24V.  Battery  charging  is  not  controlled  or  regulated  by  the  MPPT; 
that  functionality  is  left  to  a  separate  battery  charging  circuit  incorporated  between  the  MPPT 
and  the  battery. 

Battery  Charging  Circuit  (D.  Ainge) 

The  battery  charging  circuitry  is  responsible  for  safely  charging  and  discharging  the  batteries.  To 
do  this,  the  circuit  must  provide  the  batteries  with  a  constant  current  and  sufficient  voltage. 

Based  on  the  expected  depth  of  discharge  during  normal  operations,  the  CASTOR  charging 
circuit  must  provide  2A  and  30V  to  the  cells.  Unlike  terrestrial  chargers,  the  onboard  charging 
circuit  must  be  extremely  efficient  to  avoid  unacceptable  power  loses.  After  researching  both 
analog  and  integrated  ways  to  accomplish  this,  the  power  team  decided  on  an  analog  circuit 
because  of  its  extremely  low  power  consumption.  The  platform  circuit  chosen  is  shown  below. 


FIGURE  2.6-1:  SCHEMATIC  OF  BATTERY  CHARGING  CIRCUIT 

This  circuit  has  two  main  functions:  providing  constant  current  to  the  NiCd  battery  cells  and 
automatically  shutting  off  current  flow  at  full  charge.  Current  regulation  is  accomplished  by 
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using  a  transistor  (Q3)  in  parallel  with  a  resistor  (R8).  The  transistor  sets  a  constant  voltage 
(specified  by  the  part)  across  the  resistor  which  in  turn  sets  the  current  according  to  I=V/R. 

Using  a  MOSFET  at  Q2  allows  higher  current  to  flow  to  the  batteries  -  with  a  0.3  Q  resistor  as 
shown  the  current  is  2A. 

The  automatic  shut-off  function  is  accomplished  using  two  capacitors,  Cl  and  C3.  When  the 
NiCd  cells  reach  full  charge  their  internal  potential  drops  by  approximately  20mV.  The  potential 
of  C3  reflects  the  potential  of  the  battery  at  all  times,  however  the  potential  of  Cl  lags  that  of  C3 
because  of  the  circuit's  time  constant.  This  means  that  Cl  serves  as  a  reference  potential  -  when 
its  value  is  greater  than  that  of  C3  the  voltage  in  the  battery  must  be  falling.  This  will  cause  that 
the  output  of  the  operational  amplifier  to  go  high,  shutting  of  transistor  Q1  and  therefore  the 
entire  charging  circuit. 

The  circuit  as  shown  in  Figure  2.6-1  has  been  assembled  on  a  prototyping  board  using  off-the- 
shelf  components;  now  we  will  test  the  circuit  to  prove  current  stability  under  a  variety  of 
operating  conditions.  The  second  stage  of  the  circuit  design  will  involve  both  determining  the 
exact  current  needed  by  the  batteries  and  accounting  for  inherent  power  losses  —  allowing  us  to 
tailor  the  design  to  the  CASTOR  power  system.  With  this  complete,  we  will  have  the  circuit 
printed  on  PCB,  order  any  necessary  additional  circuit  components,  and  assemble  the  board. 

Plans  for  Integrated  Circuitry 

Only  after  the  analog  charging  circuit  has  been  completed  will  we  begin  to  explore  the 
possibility  of  using  imbedded  circuitry  to  handle  charging  logic.  This  will  ensure  that  should 
hiccups  arise  from  the  use  of  the  micro-controller  we  will  have  a  comparable  and  functional 
charging  circuit. 

The  analog  circuitry  uses  a  hard  switch  to  turn  charging  on  and  relies  on  the  Q1  transistor  to  shut 
charging  off.  After  a  shut-off  the  switch  must  be  reset  and  re-triggered  to  again  begin  charging. 
As  chip  logic  (provided  by  the  avionics  subsystem)  will  dictate  when  charging  begins,  it  is 
natural  to  also  use  chip  logic  to  sense  a  full  charge  and  terminate  the  charging  cycle.  By  using  a 
dedicated  micro-controller  on  the  charging  circuit  we  would  also  be  able  to  take  over  the 
responsibility  of  stimulating  charging  and  would  rely  only  on  a  trigger  from  avionics. 

Inhibits  (D.  Odhiambo) 

CASTOR  will  utilize  a  Lightband  separation  switch  to  check  for  separation  between  the  launch 
vehicle  and  the  CASTOR  satellite.  Immediately  after  separation,  power  from  the  solar  panels  is 
able  to  flow  into  the  batteries  but  not  the  rest  of  the  electrical  components.  Only  after  separation 
is  confirmed  is  the  solar  panel  power  allowed  into  the  electrical  components.  This  confirmation 
will  be  by  use  of  a  comparator  operating  between  the  24V  from  the  solar  panel  and  12V. 

Here  the  12V  input  is  an  arbitrary  design  choice  (a  voltage  value  halfway  between  0V  and  24V), 
where  other  values  greater  than  12V  but  less  than  24V  can  be  proven  to  work  just  as  well,  that 
compensates  for  the  lack  of  internal  hysteresis  when  using  an  OpAmp  in  open  loop  configuration 
as  a  voltage  comparator. 

There  is  no  guarantee  that  the  entire  solar  array  will  be  illuminated  at  separation,  and  as  such  no 
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guarantee  of  a  constant  24V  output  at  the  time  of  separation.  Therefore  designing  the  inhibit 
system  to  exhibit  electrical  hysteresis  is  necessary  as  this  provides  a  dead  band  where  voltage 
comparable  to  24V  is  let  through  to  supply  the  comparator. 

The  12V  is  supplied  by  a  voltage  regulator  that  operates  at  24V.  The  comparator  takes  in  the  two 
voltage  inputs  and  sets  its  output  value  to  the  higher  of  the  two  (24V).  Aft  of  the  comparator  are 
a  series  of  DPDT  relay  switches  used  to  connect  the  solar  panel  voltage  to  the  rest  of  the  satellite 
electrical  components.  To  avoid  the  need  for  voltage  amplification  DPDT  relay  switches  with  a 
pick-up  voltage  rating  of  24V  will  be  sourced. 

NB:  An  additional  [DPDT  relay  switches]  is  used  to  switch  off  the  inhibits  logic  circuit  in  order 
to  conserve  power  once  separation  has  been  confirmed. 


FIGURE  2.6-2:  POWER  ARCHITECTURE  SHOWING  INHIBIT  CIRCUIT  COMPONENTS 


PPU 

The  function  of  the  Power  Propulsion  Unit  is  to  distribute  the  power  drawn  from  the  system 
power  bus  (from  the  MPPT)  to  the  various  components  that  comprise  the  propulsion  system, 
namely:  the  cathode  heater,  the  cathode  keeper  and  the  anode.  The  PPU  board  has  three  power 
converters:  a  24V  to  15V  converter  to  power  the  cathode  heater,  a  24V  to  36V  converter  to 
power  the  keeper  and  a  24V  to  200V  to  power  the  anode  and  the  xenon  feed  system. 

PDU 

The  Power  Distribution  Unit  (PDU)  is  intended  to  supply  power  to  structure,  thermal, 
communication,  avionics  and  ADCS  expect  the  reaction  wheels  and  the  magnetic  torque  coil.  It 
must  supply  proper  voltage  and  current  levels  to  the  spacecraft  electronics  and  be  fully 
controllable  by  the  avionics  computer. 
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2.6.2  OVERVIEW  OF  THE  PPU  REDESIGN  (D.  ODHIAMBO) 
RELEVANT  SYSTEM  REQUIREMENTS 


■  Provide  150Wnominai  to  DCFT  while  operating 

■  130Wnominai  to  the  DCFT  Anode 

■  Provide  15Wnominai  to  the  DCFT  while  not  operating 


SUMMARY  OF  CURRENT  PPU  DESIGN 


The  function  of  the  Power  Propulsion  Unit  is  to  distribute  the  power  drawn  from  the  system 
power  bus  (from  the  MPPT)  to  the  various  components  that  comprise  the  propulsion  system, 
namely:  the  Cathode  Heater,  the  Cathode  Keeper  and  the  Anode.  The  PPU  board  has  two  power 
converters:  one  steps  down  the  bus  voltage  supplied  by  the  MPPT  from  24V  to  15V  for  the 
Cathode  Heater,  while  the  other  steps  up  the  voltage  from  24V  to  300V  for  the  Anode. 

It  was  decided  that  the  24V  to  36V  converter  was  obsolete.  The  keeper  no  longer  requires  36V 
and  can  operate  at  24V  optimally.  All  of  the  components  on  the  PPU  board,  in  particular  the 
BuckPuck,  could  also  work  at  24V  instead  of  36V.  The  removal  of  this  converter  decreases  the 
complexity  of  the  system,  while  also  significantly  increasing  efficiency. 

A  summary  of  the  voltage  breakdowns  is  shown  in  Table  2.6-1: 

TABLE  2.6-1:  VOLTAGE  REQUIREMENTS  FOR  PROPULSION  SYSTEM 


Propulsion  Component 

Voltage 

Requirement 

Current 

Requirement 

Cathode  Heater 

15V 

Cathode  Keeper 

24V 

0.5A 

Anode 

300V 

Solenoid  Valve  conditioning  (for  36  ms) 

24V 

The  diagram  in  Figure  2.6-3  further  details  the  wiring  for  the  PPU.  The  red  and  black  lines 
represent  +/-  power  lines,  while  the  blue  lines  represent  data/command  lines  between  the 
converters  and  the  avionics  computer.  The  anode  converter’s  voltage  has  been  set  at  200V. 
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To  Solar  Panels 


150W;  90% 


FIGURE  2.6-3:  PPU  ARCHITECTURE  SHOWING  PROPULSION  COMPONENTS  AND  MAX 
CAPABILITIES  OF  THE  POWER  CONVERTERS  IN  USE 


Anode  Converter 

•  Outputs  300V 

•  Delivers  150W  maximum  to  the  anode 

•  Requires  an  on/off  switch,  to  be  controlled  by  the  avionics  computer 

•  Tie  switch  between  on/off  pin  and  -Vin  (ground)  pin,  as  seen  below 

•  90%  Efficiency  (typ.)  =  15W  max  heat  generated 


Pin  # 

Single 

Dual 

2,3 

-  INPUT 

-  INPUT 

4.5 

+  INPUT 

+  INPUT 

6 

ON/OFF 

ON/OFF 

7 

Cj^SE 

CASE 

8 

N/C 

OUTPUT  2  + 

10 

N/C 

OUTPUT  2  - 

12 

OUTPUT  1  + 

OUTPUT  1  + 

14 

OUTPUT  1  - 

OUTPUT  1  • 

FIGURE  2.6-4:  ANODE  CONVERTER  (LEFT)  AND  PIN  WIRING  DIAGRAM  (RIGHT) 
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FIGURE  2.6-5:  ANODE  CONVERTER  PIN  SCHEMATIC 


Cathode  Heater  Converter 


•  Outputs  15V,  100W 

•  Requires  on/off  switch,  controlled  by  the  avionics  computer 

•  Requires  a  0.5 -1.5V  analog  control  signal,  supplied  through  a  DAC  to  the  control  pin 

•  88.5%  at  50W  and  89%  Efficiency  at  100W  =  12. 5W  or  11W  max  heat  generated 
respectively 


Shown  actual  size: 
2.28  x  1.45  x0.5  in 
57,9  x  36.8  x  12,7  mm 


FIGURE  2.6-6:  CATHODE  HEATER  CONVERTE 
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FIGURE  2.6-7:  CATHODE  HEATER  CONVERTER  WITH  CORRESPONDING  PIN-WIRING  DIAGRAM 

(RESPECTIVELY) 


Various  MOSFET-controlled  switches,  capacitors  and  resistors  are  mounted  to  the  PPU  printed 
circuit  board  in  addition  to  the  power  converters,  for  effective  power  delivery  to  the  propulsion 
subsystem  components. 

Schematics  of  the  PPU  board  prepared  using  Altium  are  available  on  fileshare  under: 

3-Sub  teams  \3.8-Power\Altium  \PPU\CASTOR  PPU  v3\ 


SUMMARY  OF  CURRENT  PDU  DESIGN  (E.  MCKINNEY) 

The  Power  Distribution  Unit  (PDU)  is  intended  to  supply  power  to  structures,  thermal, 
communication,  avionics  and  ADCS  expect  the  reaction  wheels  and  the  magnetic  torque  coil.  It 
must  supply  proper  voltage  and  current  levels  to  the  spacecraft  electronics  and  be  fully 
controllable  by  the  avionics  computer.  It  is  currently  at  Version  4. 

Power  Conversion 

Two  Lambda  CC-E  converters  have  performed  the  power  conversion.  One  is  a  5V 
converter  rated  for  15W  input  power  limit  and  the  other  is  a  3.3V  converter  rated  for  3W  input 
power  limit.  The  power  limit  has  been  picked  based  on  the  maximum  power  calculated  in  the 
power  budget,  so  that  the  converters  operate  in  the  high  efficiency  range.  Figure  2.6-8  shows  the 
circuit  diagram  for  the  5V  converter,  Figure  2.6-9  shows  the  circuit  diagram  for  the  3V 
converter,  Figure  2.6-10  shows  the  result  of  the  efficiency  test  performed  on  the  5V  converter, 
and  Error!  Reference  source  not  found,  shows  the  result  of  the  efficiency  test  performed  on  the 
3.3V  converter.  lOOpF  capacitors  have  been  placed  between  the  -V  and  +V  for  both  input  and 
output  to  minimize  voltage  ripple. 
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FIGURE  2.6-8:  THE  CIRCUIT  DIAGRAM  FOR  THE  5V  CONVERTER  RATED  FOR  1  5W  POWER  LIMIT 
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FIGURE  2.6-9:  CIRCUIT  DIAGRAM  FOR  THE  3V  CONVERTER  RATED  FOR  3W  POWER  LIMIT 
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Tested  PDU  Converter  Efficiency 
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FIGURE  2.6-10:  EFFICIENCY  RESULTS  FOR  THE  BOTH  PDU  CONVERTERS 


On/off  Switching 

Each  of  the  Lambda  converters  can  be  switched  on  and  off  using  a  MOSFET.  The 
MOSFET  are  placed  between  +Vin  pin  and  the  RC  pin.  For  the  on  mode,  the  RC  terminal  is 
brought  low  by  tying  it  to  ground,  while  for  the  off  mode,  the  RC  terminal  is  left  open  and 
internally  brought  high.  For  FlatSat  testing,  the  converters  have  been  controllable  with  both  a 
MOSFET  and  a  manual  switch  as  shown  on  Figure  2.6-8  and  Figure  2.6-9. 

Voltage  and  Current  Sensors 

Voltage  sensing  has  been  achieved  through  voltage  dividers  that  step  down  the  output 
voltages  of  the  two  CC-E  converters  by  a  half  making  the  output  voltages  below  +3.3V,  to  the 
maximum  allowable  input  into  the  avionics  computer.  The  voltage  divider  should  not  interfere 
with  the  rest  of  the  circuit,  so  100k  resistors  have  been  picked  to  make  the  dissipated  power 
minimal. 

Current  sensing  has  been  done  with  an  ACS712  hall-effect  current  sensor,  which  comes 
in  a  surface-mount  chip  package.  The  sensor,  placed  in  series  with  the  output  voltage  line  of  any 
converter,  will  generate  an  analog  voltage  signal  proportional  to  the  output  current,  which  will 
then  be  sent  to  the  avionics  computer.  From  experimental  data,  the  relationship  between  current 
and  voltage  signal  is:  Output  Voltage  [V]  =0.1831  [V/A]*Output  Current  [A]  +  2.524[V], 
approximately  183mV/A,  with  a  DC  offset  of  2.524V. 
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The  circuit  diagram  of  the  current  sensors  used  in  the  PDU  is  shown  in  Figure  2.6-1 1  and 
Figure  2.6-12.  A  lOOpF  capacitor  has  been  placed  between  the  filter  and  ground  to  filter  out  the 
noise.  Both  current  sensors  have  been  powered  by  a  5V  power  input.  The  5V  power  input  has 
been  provided  from  the  24V  input  through  a  voltage  adaptor.  The  schematic  of  the  voltage 
regulator  is  provided  in  Figure  2.6-13  .  Both  the  Isense  and  Vsense  have  been  sent  to  a  terminal 
where  they  can  be  read  by  a  multimeter,  the  Lab  View  software,  or  the  avionics  board. 
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FIGURE  2.6-1 1 :  ACS712  HALL-EFFECT  CURRENT  SENSOR  FOR  THE  5V  CONVERTER 
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FIGURE  2.6-12:  ACS712  HALL-EFFECT  CURRENT  SENSOR  FOR  THE  3.3V  CONVERTER 
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FIGURE  2.6-1 3:5V  VOLTAGE  ADAPTER 


Voltage  Regulator 

A  3.3V  voltage  reference  has  been  used  to  provide  a  3.3V  reference  voltage  to  the 
avionics  computer,  for  precision  ADC.  The  avionics  computer  needs  a  reference  voltage  with  a 
high  precision;  thus,  the  LTC6652,  a  low  drift  and  low  noise  buffered  reference  voltage,  has  been 
picked.  The  LTC6652  has  a  tolerance  of  0.05%,  a  voltage  input  of  5V  provided  from  the  voltage 
adaptor  shown  in  Figure  2.6-13,  and  a  voltage  output  of  3.3V.  The  circuit  diagram  of  the  3.3V 
voltage  reference  is  provided  in  Figure  2.6-14.  A  0.1  uF  capacitor  bypass  Vin  to  GND  and  a  10 
uF  capacitor  bypass  Vout  to  ground.  These  capacitors  have  been  added  to  improve  precision  and 
the  value  has  been  picked  according  to  the  data  sheet. 


j  3  Visf 


FIGURE  2.6-14:  CIRCUIT  DIAGRAM  FOR  THE  3.3V  VOLTAGE  REFERENCE 

Connectors 

7  Connectors  have  been  used  in  the  PDU  board  to  achieve  the  following  functionalities: 
input  +24V,  output  +5V,  output  +3.3V,  output  a  reference  +3.3V  to  the  avionics  computer,  sense 
the  voltage  and  current  for  the  5V  converter,  sense  the  voltage  and  current  for  the  3.3V 
converter,  and  input  commands  from  the  avionics  computer  to  turn  on  and  off  the  5V  converter. 
In  addition,  we  have  two  diodes  to  show  when  the  converters  are  on  and  off.  Figure  2.6-15  shows 
the  schematics  off  all  the  connectors  and  the  diodes  that  are  in  the  PDU. 
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FIGURE  2.6-15:  CIRCUIT  DIAGRAMS  FOR  THE  CONNECTORS  AND  DIODES  ON  THE  PDU 

Overall  design 

The  current  PDU  designed  has  the  properties  shown  in  Table  2.6-2,  and  the  PCB  board 
layout  is  shown  in  Figure  2.6-16.  On  PCB  layout,  the  green  color  represents  ground  traces 
and  is  situated  on  the  bottom  layer  of  the  PCB,  while  the  yellow  color  represents  positive 
traces  and  is  situated  in  the  top  layer.  The  board  has  three  different  ground  traces  based  on 
the  fact  that  the  input  and  output  ground  of  each  converter  needs  to  be  isolated.  The  bottom 
yellow  trace  represents  the  input  +24V,  the  yellow  trace  on  the  top  left  represents  the  +3.3V 
output,  and  the  yellow  trace  on  the  top  right  represents  the  +5V  output. 


TABLE  2.6-2:  PROPERTIES  OF  THE  CURRENT  PDU 


Component 

Digikey  Number 

Number  of  Components 

Cost 

The  PDU  board 

non  applicable 

1 

$33 

3.3  V  Converter 

445-2474-ND 

1 

$11.37 
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Component 

Digikey  Number 

Number  of  Components 

Cost 

5  V  Converter 

CC 15 -2405 

1 

$36.39 

Current  sensor 

620-1 191-1-ND 

2 

$3.3 

3.3  V  ref 

LTC6652AHMS8-5#PBF-ND 

1 

6.73 

5  V  adaptor 

LM2936MX-5.0TR-ND 

1 

$2.38 

Heather 

A98333-ND 

7 

$4.55 

100k  Resistor 

P 1 00KADCT -ND 

6 

$.99 

MOSFET 

IRFD123 

1 

$1.5 

Switch 

EG2610CT-ND 

2 

$14.2 

lOOpF  capacitors 

399-1022-1-ND 

6 

$0.12 

Diode 

160-1579-2-ND 

2 

$0.8 

Capacitor  (O.luF) 

478-5778-1-ND 

1 

$0,901 

capacitor  (lOuF) 

PCC2479CT-ND 

1 

$0.56 

Total 

$121.62 
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Figure  2.6-16:  PCB  Layout  for  the  PDU 


2.6.3  SOLAR  PANELS  (E.  MCKINNEY) 

The  solar  panel  design  uses  a  total  of  four  panels  arranged  such  that  two  panels  are  at  a  90  degree 
angle  to  one  another  and  mounted  to  the  body  of  the  satellite,  and  the  others  are  deployable 
panels  attached  at  135  degree  angles  to  the  edges  of  the  inner  panels  as  shown  in  Figure  2.6-17. 
There  is  1 .139m"  of  total  solar  panel  area  (not  all  of  which  is  covered  with  solar  cells),  consisting 
of  six  0.586m  x  0.486m  panels  with  96  cells  each  in  an  8x  12  configuration,  depending  on 
whether  or  not  the  solar  panel  is  deployable  or  attached.  The  cells  are  space-grade  silicon  cells, 
donated  by  Loral  Space  Systems,  and  are  6.91cm  x  3.59cm  x  0.4cm  and  have  16%  efficiency. 
The  cells  have  cover  glass  over  their  sun-facing  surface,  and  are  attached  to  a  rigid  backing  using 
space-rated  RTV  adhesive.  The  backing  is  honeycomb  aluminum  sandwiched  between  two  FR4 
printed  circuit  boards  (PCB),  bonded  using  ceramic  epoxy  that  electrically  insulates  them  while 
also  conducting  heat  from  the  cells  to  the  back  surface  of  the  panels.  To  ensure  manufacturing 
integrity,  these  backing  panels  need  to  be  ordered  instead  of  fabricated. 
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FIGURE  2.6-17:  SOALR  PANEL  LAYOUT 


RELEVANT  SYSTEM  REQUIREMENTS 


The  spacecraft  shall  have  a  wet  mass  under  50  kg. 

Thus  the  backing,  support  structure,  and  coverglass  for  the  solar  panels  must  be  no  thicker  than 
necessary  to  protect  the  cells  from  breaking  and  to  electrically  insulate  them  from  conductive 
metal  structures. 

S9.5.4.1 1  The  structure  shall  fit,  collapse,  or  fold  down  to  fit  within  50cm  X  50cm  X  60cm  in 
order  to  fit  UNP  specifications. 

Thus  the  Structures  Team  requires  that  the  solar  cells  fit  on  an  area  of  56.8cm  x  46.8cm  per  panel 
so  that  they  will  have  room  to  attach  their  hinges  to  the  panel  edges.  Their  design  requires  that 
the  total  panel  area  be  58cm  x  48cm. 


S7.1  The  spacecraft  shall  contain  a  power  subsystem  capable  of  supplying  a  continuous  source  of 
electrical  power  to  spacecraft  loads  during  the  mission  life. 

Each  of  the  subsystems'  equipment  pieces  only  require  power  for  a  fraction  of  the  total  time  of 
the  cycle,  and  the  most  power  intensive  are  summarized  in  Table  2.6-3.  This  allows  both  the 
batteries  to  be  charged  and  the  thruster  to  be  fired,  all  within  the  169.95W  that  the  solar  panels 
produce  when  in  direct  sunlight. 


TABLE  2.6-3:  POWER  BUDGET  SUMMARY 


Subsystem  -  Sun  Cycle 

Power  Required  (Watts) 

All  systems  -  Eclipse 

23.92 

All  systems  -  Sunlight 

121.25 

Charging  batteries  -  sunlight 

69.47 
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Thruster  firing  -  sunlight 


103.13 


Mass  and  Cost  Budget 

Some  of  the  purchases  listed  below  were  made  through  donations,  and  for  others,  minimum 
purchase  requirements  made  it  necessary  to  buy  more  of  an  item  than  will  be  used  in  the  design. 

TABLE  2.6-4:  MASSES  AND  COSTS  OF  SOLAR  PANEL  COMPONENTS 


Item 

Quantity 

Total  Cost 

Total  Mass 
Used  (kg) 

Solar  cells  1 

416 

Free 

0.874 

FR4  PCB  5 

8  sheets,  0.58m  x  0.48m 

$528.00 

0.65 

.74  cm  thick  carbon  fiber  composite3 

4  sheets,  0.58m  x  0.48  m 

$671.96 

2.43 

150  micron  thick  coverglass2 

4  sheets,  0.565m  x  0.45m 

Free 

0.375 

500°F  Duralco  128  ceramic -based 
epoxy4 

-10%  of  panel  mass 

$129.90 

0.487 

NuSil  CV10-2568  RTV  adhesive 

1  kit 

$463.50 

0.250 

Total 

$1,793.36 

5.066 

1.  The  solar  cells  are  free,  donated  by  Loral  Space  Systems. 

2.  The  coverglass  is  donated  by  Loral’s  supplier,  Qioptiq. 

3.  The  carbon  fiber  composite  with  honeycomb  comes  from  Protech  Composites. 

4.  The  ceramic  epoxy  comes  in  8-ounce  containers,  and  10%  of  the  panel  mass  is  about  15.7 
ounces,  so  two  containers  would  be  needed. 

5.  The  PCB  will  be  designed  in  Altium  and  ordered  through  the  software. 


SOLAR  PANEL  DIMENSIONS 

The  Structures  Team  has  determined  that  each  solar  panel  can  be  at  most  0.58m  x  0.48m,  with 
0.568m  x  0.468m  for  the  solar  cells  and  coverglass  and  the  rest  for  structural  interfaces  like 
hinges.  The  dimensions  of  the  solar  panels  were  set  not  by  the  power  requirements,  but  by  the 
space  restrictions  of  the  UNP.  Within  UNP  constraints,  solar  cell  area  was  maximized  to 
maximize  power,  and  any  power  beyond  the  vehicle’s  minimum  functional  needs  will  go  to  the 
thruster  to  increase  the  force  from  the  propulsion  system.  Four  panels  of  this  size  are  sufficient 
because,  as  shown  below,  they  can  provide  169W — enough  power  to  fire  the  thruster  and  run  the 
other  subsystems  with  additional  watts  to  accommodate  power  usage  spikes  among  the 
subsystems  and  to  allow  the  thruster  to  operate  at  higher  power  (greater  thrust)  when  possible. 
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The  orientation  of  the  solar  cells  on  the  panels  was  designed  to  maximize  the  number  of  cells 
that  will  fit  and  therefore  maximize  power  output.  The  design  will  use  a  96-cell  arrangement 
with  an  array  of  12  cells  by  8  cells.  Loral  Space  Systems  has  agreed  to  donate  cells  that  have 
6.91cm  x  3.59cm  faces  and  are  0.4cm  thick.  There  are  two  ways  to  fit  these  cells  onto  a  0.5m  x 
0.62m  panel:  align  the  long  side  of  each  cell  with  the  long  side  of  the  panel,  or  align  the  short 
side  of  each  cell  with  the  long  side  of  the  panel.  Using  the  former  method,  96  cells  have  been 
shown  to  fit  on  the  panel. 

The  minimum  allowable  distance  between  cells  is  1.5mm,  both  between  rows  and  between 
columns.  This  margin  provides  room  for  the  wiring  between  cells  and  lessens  the  danger  of  cells 
touching  and  either  shorting  out  or  transferring  loads  to  each  other  that  could  cause  them  to 
shatter. 

To  account  for  wires  that  connect  the  solar  panels  to  the  rest  of  the  satellite,  holes  will  need  to  be 
cut  in  the  open  spaces  on  the  panels  for  the  wires  to  transfer  through. 

POWER  OUTPUT 

With  96  cells  for  each  of  the  4  panels,  at  6.91cm  x  3.59cm  each,  the  total  power-generating  area 
on  each  panel  is  0.238m'.  The  maximum  power  generated  can  be  calculated  using  the  equation 
below. 

P  —  Qsoiar  A^inppt^glass^ccll  sill( 0) 


A  =  total  solar  cell  area  =  0.982m2 

Qsoiar  =  the  solar  power  constant  =  1350  W/m2 

Eceii  =  solar  cell  efficiency  =  0.16 

£  glass  =  efficiency  of  transmittance  of  usable  light  through  coverglass  =  0.94 
£mPPt  =  efficiency  of  maximum  power  point  tracker  (MPPT)  =  0.95 

9  =  the  smallest  angle  between  the  light  vector  and  the  panel’s  surface  =  90°  for 
deployable  panels,  45°  for  body  mounted  panels 

P  =  power  output  from  solar  panels  after  passing  through  MPPT  due  to  MPPT 
inefficiencies  =  156W 

For  the  standard  Qsoiar  of  1350  W/m2  and  the  Loral  solar  cell  efficiency  of  16%,  the  total  panel 
area  above  gives  165W.  This  is  the  maximum  power  output  when  the  deployable  panels 
face  the  sun  directly  (0  =  90°),  and  the  body  mounted  panels,  by  geometry  face  the  sun  at 
45°  which  they  should  for  most  of  the  mission  thanks  to  actuators  from  the  ADCS  Team. 
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ELECTRICAL  LEADS 

The  leads  that  connect  to  the  front  of  one  cell  will  connect  to  the  back  of  the  next  cell.  The  cells 
used  for  this  design  are  rectangular  and  not  octagonal  like  the  cells  in  Ligure  2.6-18,  but  the 
connections  are  the  same,  using  flux  and  tinned  tabbing  wire.  With  this  type  of  connection,  a 
column  of  cells  will  typically  be  connected  in  series,  but  since  the  MPPT  is  designed  for  nominal 
voltages  24V-36V,  and  each  cell  provides  -0.5V  based  on  the  power  analysis  above,  there  must 
be  48-72  cells  in  each  series  to  provide  voltage  within  this  range.  With  13  cells  per  column  and 
8  columns  per  panel,  there  are  two  series  of  cells  per  panel,  each  with  4  columns.  These  series 
provide  roughly  24V,  which  is  at  the  lower  end  of  the  MPPT’s  range. 

The  solar  cells  are  expected  to  degrade  by  10%  by  the  end  of  a  year  in  space,  according  to  the 
team’s  contact  at  Loral,  so  the  voltage  to  the  MPPT  would  decrease  to  21.6V.  It  will  be 
necessary  to  run  the  MPPT  with  an  adjustable  voltage  source  to  see  how  it  performs  under  these 
conditions. 

In  terms  of  wiring,  tabbing  wire  connects  the  bottom  of  one  column  to  the  top  of  the  next  when 
the  two  columns  are  in  series,  and  this  next  column  is  oriented  “upside  down”  compared  to  the 
first  column,  in  terms  of  the  direction  of  the  tabbing  wire  weaving  from  one  cell  to  the  next.  The 
two  series  each  have  a  positive  and  negative  lead,  and  all  the  leads  are  on  the  same  side  of  the 
panel.  The  two  positive  leads  are  connected  to  each  other  using  tabbing  wire,  as  are  the  negative 
leads,  so  that  the  panel  has  two  leads  total.  These  leads  are  on  opposite  sides  of  the  panel  so  that 
the  panels  can  be  connected  in  parallel  with  their  longer  edges  adjacent  to  each  other.  16  AWG 
insulated  wire  connects  the  strings,  and  12  gauge  wire  connects  the  panels  to  each  other  and  to 
the  MPPT. 

Diodes  at  the  end  of  each  series  of  cells  prevent  backflow  of  current  in  case  the  voltage  across 
that  series  is  not  sufficient  to  produce  current  in  the  desired  direction.  If  a  series  does  not 
produce  current,  the  mission  is  still  viable,  but  there  will  be  approximately  23W  less  power 
output.  If  a  solar  cell  shatters,  its  tabbing  wire  connections  tend  to  stay  intact  (based  on 
accidents  during  prototyping  when  cells  shattered),  the  particular  series  of  cells  will  be  unable  to 
provide  power,  and  the  satellite  will  lose  approximately  1/8 th  of  its  power.  The  mission  can  still 
continue  without  this  power  due  to  the  power  margin  provided,  but  the  frequency  and  duration  of 
the  thruster  firing  will  have  to  be  reduced. 

Electrical  leads,  “Weaving”  Prom  the  Front  of  one  cell  to  the  back  of  the  next  is  shown  in  Ligure 
2.6-18.  The  directionality  of  this  top-to-bottom  connection  determines  the  direction  of  current 
along  the  series.  There  must  be  enough  space  between  cells  to  allow  this  connection. 
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FIGURE  2.6-18:  SOLAR  PANEL  FABRICATION 


COVERGLASS 

The  ideal  design  uses  as  much  blue/red  reflector  (BRR)  coated  glass  as  possible,  distributed 
evenly  among  electrical  series  on  the  panels  so  that  all  series  have  the  same  voltage,  and  covers 
the  remaining  cells  with  anti-reflection  (AR)  coated  glass.  The  glass  Qioptiq  has  offered  to 
donate  is  150  micron  thick  CMX  with  BRR  coating,  but  Qioptiq  only  has  enough  of  this 
coverglass  for  160  cells  and  thus  more  will  need  to  be  obtained.  They  have  enough  AR  glass  to 
cover  all  the  cells  in  the  design.  JDSU  has  also  offered  to  donate  coverglass,  100  micron  BRR 
CMX  glass,  so  these  covers  would  be  lighter,  but  it’s  uncertain  how  many  JDSU  will  be  able  to 
donate,  so  the  current  design  the  Qioptiq  glass  for  all  cells.  BRR  glass  is  more  desirable  because 
it  reflects  wavelengths  of  light  that  the  solar  cells  cannot  use.  The  energy  of  this  light  would 
only  become  heat  without  providing  electricity,  and  the  additional  radiation  would  speed  the 
cells’  degradation.  Other  wavelengths  are  not  reflected,  and  as  with  AR  coating,  this  lack  of 
reflection  means  more  useable  light  hitting  the  cells. 

For  comparison,  the  properties  of  CMX  glass  and  several  other  coverglass  types  are  documented 
in  Table  2.6-4.  The  glass  comes  in  6.923cm  x  3.604cm  pieces,  just  slightly  bigger  than  the  cells, 
so  with  1.5mm  gaps  between  cells,  there  would  be  1mm  and  1.37mm  gaps  between  coverglass 
pieces. 


Property 

CMX 

CMG 

CMO 

Corning  0213 

Corning  0214 

Density  (g/cnr) 

2.605 

2.554 

2.536 

2.6 

2.5 

Refractive  index 

1.5265 

1.516 

1.490 

1.528  at 

589nm 

1.516  at  589nm 

Young’s  Modulus 
(GN/m2) 

75±1.0 

78.7±1.0 

69±1.0 

73.7 

73.0 
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Poisson’s  Ratio 

0.22±0.01 

0.175±0.01 

0.22±0.01 

0.224 

0.22 

Thicknesses 
available  (mm) 

0.05-0.50 

0.05-0.50 

0.05-0.50 

0.075-0.50 

0.075-0.50 

TABLE  2.6-4:  SOLAR  CELL  COVERGLASS  PROPERTIES 


The  reason  to  use  coverglass  is  that  power  output  can  be  increased  if  the  glass  protects  the  cells 
from  infrared,  ultraviolet,  and  particle  radiation  that  would  degrade  the  cells’  efficiency.  The 
glass  can  also  decrease  power  output  by  not  allowing  all  photons  that  hit  the  panel  to  reach  the 
solar  cells,  but  the  Power  Team’s  Loral  contact  explained  that  in  practice  there  is  a  net 
improvement  in  power  output.  These  effects  on  power — the  glass’  transmittance  of  light  and  its 
effectiveness  at  protecting  the  cells — have  not  been  quantified  by  the  manufacturers.  The 
transmittance  efficiency  sgiassused  above  is  based  on  information  from  the  team’s  contact  at 
Loral. 

The  benefits  of  increasing  the  efficiency  of  the  cells  are  currently  being  weighed  by  the 
manufacturing  difficulties  of  installing  the  cover  glass.  Currently,  the  decision  is  to  continue  with 
the  use  of  cover  glass. 


SUPPORT  STRUCTURE 


Since  the  solar  cells  are  extremely  brittle,  shattering  in  a  person’s  hand  under  minimal  bending 
loads,  the  solar  panels  must  be  rigid  to  protect  the  cells  from  bending,  especially  during  launch 
and  deployment.  The  current  design  is  !4  inch  (0.635cm)  thick  honeycomb  aluminum 
sandwiched  between  two  0.020  inch  carbon  fiber  composite  sheets  (0.01016  cm).  This 
manufacturing  will  be  outsourced. FR4  PCB  with  thickness  of  0.005  cmwill  then  be  epoxied  to 
carbon  fiber  on  either  side.  The  sandwich  structure  is  shown  in  Figure  2.6-20.  With  the  tall,  thin, 
hexagonal  honeycombs  to  provide  structural  strength  along  one  axis  (the  axis  perpendicular  to 
the  panel)  and  the  carbon  fiber  composite  and  PCB  to  provide  strength  along  the  other  two  axes, 
this  panel  is  more  rigid  than  the  alternative  designs,  which  used  an  aluminum  plate  with  holes  to 
reduce  mass.  The  PCB  simplifies  the  wiring  of  the  cells  and  eliminates  the  need  for  Kapton  tape. 
Enough  sandwich  material  for  one  solar  panel  would  weigh  0.38kg,  compared  to  the  1.30kg 
1/16-inch  aluminum  panel  design  in  Figure  2.6-20.  The  solar  cells  are  sealed  against  this  backing 
under  the  coverglass.  The  PCB  and  honeycomb  are  attached  to  each  other  using  thermally 
conductive,  electrically  insulating  ceramic -based  epoxy  as  shown  in  Figure  2.6-20.  This  epoxy 
doesn’t  outgas  unless  its  max  temperature  of  533. 15K  is  exceeded.  The  solar  cells  require  a 
different  adhesive  to  bind  them  to  the  backing,  a  space-rated  RTV  adhesive  like  NuSil,  which  is 
the  current  choice  due  to  its  lower  price  compared  to  Dow  Corning  at  no  cost  to  quality. 
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FIGURE  2.6-19:  A  1/16  INCH  THICK  ALUMINUM  DESIGN 
It  was  rejected  because  it  was  heavier  and  less  rigid  than  the  honeycomb  sandwich  structure 


ceramic  based  epoxy  Duralco  epoxy 

printed  circuit  board  —  honeycomb  aluminum 

_ cover  glass  cells 

carbon  fiber 


FIGURE  2.6-20:  A  CROSS-SECTION  OF  A  SOLAR  PANEL,  NOT  DRAWN  TO  SCALE 


2.7  SCIENCE/PAYLOAD 


2.7.J  OVERVIEW  AND  SCIENCE  CASE  (M.  KNAPP) 

CASTOR  will  carry  a  C328-7640  RBG  JPEG  camera  to  observe  the  DCFT  plume.  The 
camera’s  purpose  will  be  to  support  DCFT  operation  and  augment  measurements  of  the 
thruster’s  performance.  While  some  performance  and  efficiency  metrics  can  be  monitored  by 
other  means  (delta-V,  temperature,  etc),  the  camera  will  provide  visual  feedback  as  well  as 
independent  data  on  thruster  performance. 

The  camera  will  observe  two  main  phases  of  DCFT  operation.  During  cathode  conditioning 
(before  first  firing),  the  camera  will  capture  images  of  the  cathode.  If  operating  properly,  the 
cathode  tip  will  glow.  Once  the  camera  provides  confirmation  that  the  cathode  is  operating 
properly  during  cathode  conditioning,  the  DCFT  can  be  fired.  Cathode  function  cannot  be 
measured  by  other  means,  so  the  camera  is  essential  for  this  process.  The  camera  will  also 
confirm  that  the  thruster  is  operating  properly  (a  plume  appears)  and  that  the  plume  is  properly 
ionized  (plume  will  be  purple  to  blue  in  color).  Figure  2.7-1  shows  the  glowing  cathode  and  a 
well-ionized  plume. 
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FIGURE  2.7-1  DCFT  IN  OPERATION 


During  normal  satellite  operations,  the  DCFT  will  fire  during  each  period  of  sunlight.  During 
each  thruster  firing,  the  camera  will  take  images  that  will  serve  two  purposes.  First,  they  will 
provide  visual  confirmation  that  the  thruster  is  operating  properly.  Second,  the  color  of  the 
thruster  plume  will  be  used  to  determine  the  engine  efficiency.  RGB  data  from  the  camera  will 
be  compared  to  data  taken  on  the  ground  during  testing  in  order  to  correlate  the  observed  plume 
color  on-orbit  with  known  efficiencies  and  power  levels.  During  vacuum  chamber  testing  on  the 
ground,  plume  images  will  be  analyzed  by  binning  RGB  data  from  each  pixel  and  correlating 
those  histograms  with  the  engine  performance  data  for  the  same  time  period.  In  this  way,  RGB 
data  is  correlated  with  detailed  performance  data  so  that  RGB  data  taken  on  orbit  will  provide 
quantitative  information  on  thruster  performance. 


2.7.2  CAMERA  SPECIFICATIONS  (A.  FIDONE) 


CASTOR  will  be  using  the  C328  camera  system  with  the  7640-stylelens  (Figure  1.1. 2-1).  This 
system  will  allow  CASTOR  to  image  the  DCFT’s  plume.  During  operation,  the  camera  will  use 
its  maximum  resolution  (VGA)  of  640x480. 


FIGURE  2.7-2  C328  7640  CAMERA  BOARD  WITH  DIMENSIONS 
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As  a  quick  reference,  important  values  are  listed  in  Table  1.1. 2-1.  However,  more  detailed 
information  can  be  found  in  Tables  1.1. 2-2  and  1.1. 2-3. 


TABLE  2.7-1 :  C328  KEY  VALUES 


Field  of  View 

57  0 

Operating  Temperature  Range 

-20  and  60  °C 

Resolution  Range 

CIF  to  VGA 

Operating  Voltage 

3.3  V 

Power  Consumption 

60  mA 

TABLE  2.7-2:  PIN  DESCRIPTION  WITH  BOTTOM  VIEW  OF  C328 


Pin 

Description 

VCC 

Power  3.3VDC 

TxD 

Data  Transmit  (3.3V) 

RxD 

Data  Receive  (3.3V) 

GND 

Power  Ground 

Connector  specification:  2mm  pitch,  4pin  single  row 
Reference  part  no:  Suyin  190600 
Mating  connector:  Suyin  140600 


r - \ 


v _ y 


□ 

□ 

□ 

□ 


GND 

RxD 

TxD 

vcc 


Bottom  View 


TABLE  2.7-3  ELECTRICAL  PROPERTIES 


Voo  =  3.3V+10%.  TA  =  0  to  25°C 


Symbol 

Parameter 

Condition 

Min 

Typ 

Max 

Unit 

Voo 

DC  supply  voltage 

3.0 

3.3 

3.6 

V 

lo 

Normal  Operation  Current 

Operating 

60 

mA 

Is 

Suspend  Current 

Suspend 

100 

uA 

VlH 

High  level  input  voltage 

TTL 

2.0 

V 

VlL 

Low  level  input  voltage 

TTL 

0.8 

V 

During  flight,  the  camera  will  operate  under  the  avionics  specifications  found  in  Table  1. 1.2-4. 
The  values  below  are  calculated  with  the  resolution  of  640  x  480. 

TABLE  2.7-4:  DATE  RATES 
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Total  downlink  intervals  per  orbit 

3 

Window  of  opportunity  per  interval 

360  Seconds 

Corrected  window  (40%  loss) 

216  Seconds 

Downlink  strength 

112.5  Kilobits  per  second 

Maximum  data  downlinked  per  interval 

24,300  Kilobits 

Total  allocated  storage  for  imaging 

0.5  Gigabytes  =  4,194,304  Kilobits 

Total  size  of  each  image 

240  Kilobits 

Total  images  per  interval  that  can  be 
transmitted 

101 

The  margin  value  for  other  downlink/uplink  activities  is  67%  i.e.  the  C328  will  use  33%  of  the 
downlink  capacity  per  interval  to  downlink  images. 

Concept  of  Operations 

After  initial  launch,  the  camera  system  will  begin  monitoring  the  cathode  activation  sequence. 
During  this  phase,  it  will  capture  an  image  every  10  minutes  until  the  cathode  is  fully 
operational,  a  condition  which  is  indicated  by  the  cathode’s  spectral  resolution.  The  cathode  is 
expected  to  remain  activated  for  the  remainder  of  the  mission. 

Each  time  the  thruster  fires,  the  camera  will  capture  one  image  every  two  minutes  to  monitor 
thruster  functionality.  The  thruster  is  expected  to  remain  active  for  22-30  minutes,  yeilding  a 
maximum  of  15  images. 

The  camera  may  also  be  used  to  take  extra  images  To  Be  Determined  but  will  amount  to  no  more 
than  a  few  images  for  any  given  interval. 

Throughout  each  interval,  the  system  is  expected  to  yield  approximately  33  images,  which  falls 
below  the  maximum  capacity  of  140  images.  This  leaves  a  substantial  margin  for  other  downlink 
activities  of  about  75%  (of  maximum  downlink  capability  per  interval). 


2.7.3  MASS  BUDGET  (A.  FIDONE) 


Table  1.1.2-5  documents  the  mass  of  the  camera  system. 

TABLE  2.7-5:  MASS  BUDGET 
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Component 

Mass  (g) 

Camera 

8 

Wires 

3 

6061  Al  Shield 

26.74 

2.7.4  SHIELDING  (M.  KNAPP) 


The  DCFT  will  create  a  high  flux  of  high-energy  ions  in  the  region  posterior  to  its  position. 
These  ions  can  damage  components  like  the  camera,  so  the  camera  must  be  shielded  to  ensure 
that  it  functions  properly  for  the  duration  of  the  satellite  lifetime. 

It  is  necessary  to  construct  an  aluminum  encasement  for  the  camera  to  protect  it  from 
degradation  and  deposition  caused  by  the  ions  released  from  the  thruster.  It  will  be  made  of  an 
aluminum  alloy  of  approximately  1.5  mm  in  thickness.  This  box  will  be  approximately 
1.25x1x0.5  in  and  positioned  a  maximum  distance  of  353.5  mm  from  the  central  axis  of  the 
satellite  (at  a  corner  of  the  CASTOR  structure).  It  will  be  secured  to  a  structural  truss  with  two 
#4  screws. 

The  encasement  will  be  equipped  with  a  bi-stable  (latching)  shutter  provided  by  Brandstrom 
Instruments  (DWG  No:  A1037).  The  shutter  will  be  controlled  by  electrical  impulses  (at  a 
maximum  of  5V),  causing  the  15x1 5 mm  blocker  to  alternate  between  opened  and  closed  states. 

It  will  be  constructed  from  black  anodized  aluminum  and  other  low  outgassing  materials.  Figure 
1.1. 4-1  shows  a  preliminary  design  for  this  shutter. 


FIGURE  2.7-3:  SHUTTER  DIMENSIONS 


2.7.5  CAMERA  TESTING  (M.  SQUIERS) 


To  verify  the  sustainability  of  the  camera,  it  is  necessary  to  perform  the  following  tests  with  the 
ultimate  aim  of  simulating  the  mission-like  conditions  of  a  space  environment:  the  Thruster,  Thermal 
Vacuum,  Avionics,  Vibration  I  &  II,  and  Integrated  Camera  Function  Tests. 
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The  Thruster  Test  will  be  used  to  assess  both  the  functionality  of  the  lens  after  exposure  to  the 
ion-saturated  environment  posterior  to  the  ignited  thruster  and  the  effectiveness  of  shielding  materials.  A 
stand  was  equipped  with  the  7640-style  lens  and  three  separate  aluminum  alloys  of  varying  masses  and 
thicknesses  (Table  1. 1.5-1).  The  stand  was  then  placed  in  a  vacuum  chamber  approximately  30cm 
perpendicular  from  the  central  axis  of  the  thruster,  and  the  thruster  was  run  through  a  flight  simulation. 
Upon  return  to  atmospheric  conditions,  the  samples  were  removed  and  massed.  At  this  time,  the  lens  has 
been  left  in  the  chamber  for  further  exposure.  After  the  thruster  is  allowed  to  run  through  approximately 
three  additional  thruster  cycles,  the  lens  will  be  removed  and  massed.  The  lens  will  be  used  to  take  images 
that  will  be  compared  to  pre-test  images  and  evaluated  based  on  their  relative  clarity. 

In  addition  to  the  image  clarity  assessment,  the  effective  degradation  of  and  deposition  on  the  lens 
and  aluminum  alloys  will  be  evaluated  based  on  a  percent  mass  difference.  The  passing  criteria  of  this  test 
include:  high  clarity  of  post-exposure  images  and  little  to  no  degradation/deposition  of  the  acceptable 
aluminum  samples.  If  the  lens  cannot  take  clear  images,  a  shutter  must  be  purchased.  Since  the  aluminum 
samples  show  minimal  degradation/deposition,  the  lowest  density  aluminum  with  minimal  thickness  will 
be  used  to  construct  the  camera  encasement.  (Expected  completion  date:  May  2010) 


TABLE  1 . 1 .5  - 1 :  Mass  of  components 


Component 

Pre-Test  Mass  (g) 

Post-Test  Mass  (g) 

Lens 

0.5720 

- 

Alloy  1:  20/24 

39.25 

39.27 

Alloy  2:  50/52 

52.41 

52.46 

Alloy  3:  60/61 

57.32 

57.40 

The  Thermal  Vacuum  Test  is  to  be  performed  to  determine  the  overall  durability/functionality  of 
the  camera  in  a  thermal/vacuum  environment  comparable  to  that  expected  in  space.  The  camera  will  be 
equipped  with  five  Resistive  Thermal  Devices  (RTDs)  to  monitor  the  temperatures  the  camera  reaches  as 
a  result  of  the  thermal  conditions  in  the  chamber.  The  chamber  will  be  brought  down  to  a  vacuum  and  run 
through  a  five  orbit  thermal  cycle.  Throughout  this  process,  the  camera  will  be  programmed  to  take 
images  of  six  mounted  LED  lights  -  two  of  each  red,  green,  and  blue.  The  passing  criteria  of  this  test 
include:  relatively  high  level  of  functionality  of  the  camera  as  monitored  through  visual  inspection  of  the 
image  capture  and  clarity.  (Expected  completion  date:  May  2010) 
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The  Avionics  Test  is  to  be  performed  to  verify  the  compatibility  between  the  camera  signal 
converter  board  and  the  CASTOR  flight  electronics  by  demonstrating  the  ability  to  capture  and  store 
images  in  the  flight  computer.  The  camera  will  be  secured  to  the  camera  signal  converter  board  that  will 
then  be  connected  to  the  flight  computer.  Power  will  be  supplied  to  both  the  camera  and  the  computer.  A 
diagnostic  routine  will  be  initiated  on  the  computer  issuing  commands  to  the  camera  to  take  images.  The 
passing  criteria  of  this  test  include:  verification  of  image  receipt  and  proper  image  storage.  (Expected 
completion  date:  May  2010  -  prior  to  the  SHOT  II  test) 

The  Vibration  Tests  I  &  II  are  to  be  performed  to  verify  the  robustness  of  the  camera  mechanical 
design  thus  ensuring  that  it  will  comply  with  launch  survival  requirements.  The  camera  and  enclosure  will 
be  affixed  to  a  shake  table.  For  Test  I  (Broadband  Dynamics),  the  broadband  profile  specified  by  the 
University  Nanosatellite  Program  will  be  used  as  the  input  dynamics.  Upon  completion  of  this  cycle,  the 
unit  will  be  removed  from  the  shake  table  and  visually /functionally  assessed.  For  Test  II  (Shock 
Foading),  the  camera  and  enclosure  will  be  re-affixed  to  the  shake  table.  A  shock  loading  will  serve  as  the 
input  dynamics.  Upon  completion  of  this  cycle,  the  unit  will  be  removed  and  assessed  as  before.  In  each 
case,  no  acceleration  data  is  to  be  recorded.  The  passing  criteria  of  both  of  these  tests  include:  the 
complete  physical  integrity  of  the  camera  enclosure  determined  via  a  visual  inspection  and  the  maintained 
electronic  functionality  of  the  camera  determined  via  an  image  capture/receipt/clarity  verification. 
(Expected  completion  date:  August  2010) 

The  Integrated  Camera  Function  Test  is  to  be  performed  to  verity  the  integrated  functionality  of 
the  camera  for  imaging  the  CASTOR  thruster  in  flight-like  conditions  by  demonstrating  the  ability  of  the 
camera  subsystem  to  effectively  monitor  the  cathode  ignition  and  plume  qualities.  This  test  is  comprised 
of  two  subtests:  the  cathode  ignition  test  and  the  plume  characterization  test.  The  satellite  with  the 
camera/enclosure  will  be  placed  in  a  vacuum  chamber  that  will  be  brought  down  to  a  vacuum.  The 
camera  will  be  initialized  such  that  an  image  is  captured  every  second.  Cathode  ignition  will  be  initialized 
and  a  response  will  be  measured  by  the  camera.  The  passing  criterion  for  this  subtest  includes: 
confirmation  of  the  cathode  ignition  by  the  camera.  After  the  cathode  has  been  ignited,  the  Diverging 
Cusped  Field  Thruster  (DCFT)  will  be  run  through  its  full  range  of  power  settings  over  a  course  of  60 
minutes.  Data  will  be  collected  from  the  camera  at  one  image  per  minute.  These  data  will  be  archived  for 
analysis  after  the  test  sequence  to  demonstrate  that  the  camera  images  can  be  used  to  characterize  the 
thruster  performance  via  plume  color  and  shape.  The  pass  criteria  for  this  subtest  includes:  the  ability  of 
applying  a  post-test  analysis  of  the  image  data  to  determine  the  thruster  energy  level  to  within  5%  of  the 
actual  level  given  by  the  known  DCFT  setting  during  the  test.  (Expected  completion  date:  September 
2010). 
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2.8  STRUCTURES 


2.8.1  SATELLITE  OVERVIEW  (E.  PETERS) 


Structural  Requirements 

The  CASTOR  structure  configuration  is  driven  by  requirements  defined  by  CASTOR 
subsystems  and  UNP1.  Key  requirements  include: 

•  Provide  a  means  of  attachment  for  all  components. 

•  Dimension  and  Mass  Requirements: 

o  Volume:  50cm  X  50cm  X  60cm. 
o  Mass:  <  50  kg. 

•  Launch  Environment  Requirements: 

o  Factors  of  Safety:  2.0  for  yield,  2.6  for  ultimate, 
o  Loading:  ±20  g  along  X,  Y,  and  Z  principal  axes, 
o  Fundamental  Frequency:  >100  Hz  in  all  directions. 

•  Center  of  Mass  Constraints: 

o  Within  40cm  of  interface  plane, 
o  Within  0.5cm  of  Lightband  centerline  (+X  Axis). 

•  Provide  sufficient  surface  area  for  solar  arrays  to  meet  power  requirements. 


Structure  Overview 

The  satellite  has  two  configurations:  the  Stowed  Configuration  and  the  Deployed  Configuration, 
which  will  occur  during  launch  and  after  launch,  respectively.  The  primary  motivation  for  a  dual¬ 
configuration  structure  is  CASTOR’S  power  requirements:  while  the  Stowed  Configuration 
meets  UNP’s  volume  and  frequency  requirements  and  has  a  higher  likelihood  of  surviving 
launch  conditions,  the  Deployed  Configuration  provides  more  solar  cell  exposure.  The  two 
configurations  are  depicted  in  Figure  2.8-1 


1  NANOSAT  6  USER’S  GUIDE.  AFRL  Space  Vehicles  Directorate.  January  2009. 
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FIGURE  2.8-1 :  CASTOR  STOWED  AND  DEPLOYED  CONFIGURATIONS 


Coordinate  System 

CASTOR’S  coordinate  system,  which  is  a  right-hand  coordinate  system,  is  reflected  in  Figures 
2.8-2  and  2.8-3  for  the  Stowed  and  Deployed  Configurations,  respectively.  These  figures  employ 
“bottom  view”  perspectives;  the  positive  X  direction  is  into  the  page,  while  the  direction  of  thrust 
is  out  of  the  page.  Note  that  the  origin  of  the  CASTOR  satellite  is  defined  geometrically  as  the 
intersection  between  the  satellite  interface  plane  (Y -Z  axis)  of  the  ESPA  Lightband  and  the 
central  axis  of  the  Xenon  tank  (X  axis). 


Coordinate  System-  Stowed 


BOTTOM  VIEW: 


NOTES: 

•  CASTOR  uses  a  Right  Hand  Coordinate  System. 

•  From  the  bottom  view,  you  are  looking  in  the  +X  direction. 

•  +X  is  in  the  direction  of  thrust. 


FIGURE  2.8-2:  COORDINATE  SYSTEM  IN  THE  STOWED  CONFIGURATION 
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Coordinate  System-  Deployed 


BOTTOM  VIEW: 


NOTES: 

•  CASTOR  uses  a  Right  Hand  Coordinate  System. 

•  From  the  bottom  view,  you  are  looking  in  the  +X  direction. 

•  +X  is  in  the  direction  of  thrust. 

FIGURE  2.8-3:  COORDINATE  SYSTEM  IN  THE  DEPLOYED  CONFIGURATION 


Recent  Modifications 

During  Spring  -  Summer  2010,  the  Structures  Team  modified  the  satellite’s  overall  structure  in 
an  effort  to:  (1)  address  CDR  feedback  regarding  ways  to  reduce  risk  and  complexity;  (2)  ensure 
that  the  satellite  will  survive  launch  conditions;  (3)  simplify  integration;  and  (4)  minimize  mass 
while  still  accomplishing  these  goals.  Specific  modifications  include,  among  others: 

1)  Modifying  placement,  interfacing,  and  mount  design  of  several  non-structural 
components  based  on  new,  higher  fidelity  models,  and  other  considerations. 

2)  Shifting  the  tank  section  up  by  10  cm,  to  raise  the  Xenon  tank  nozzle  out  of  the 
Separation  Interface  Plane 

3)  Creating  two  separate  avionics  boxes,  one  each  for  high-  and  low-voltage  components. 

4)  Revising  the  Bottom  Tank  Clamp  to  allow  for  easy  installation/removal  of  the  Xenon 
tank. 

5)  Creating  a  new  Lightband  interfacing  bracket  that  meets  structural  requirements. 

6)  Modifying  solar  panels  to  include  cut-outs  for  various  components,  and  to  meet  a  new 
understanding  of  UNP  requirements. 
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2.8.2  CAD  MODEL  (E.  PETERS) 


CAD  Overview 

The  objective  of  the  Unified  CAD  Model  (UCM)  is  to  provide  a  three-dimensional  simulation  of 
the  satellite,  including  all  parts,  components,  and  hardware.  The  UCM  is  a  helpful  tool  for 
determining  satellite  configuration,  estimating  center  of  mass  and  moments  of  inertia,  and 
performing  mechanical  and  thermal  analyses. 

The  CASTOR  UCM  is  a  SolidWorks-based  assembly  organized  by  parts  and  subassemblies 
using  a  six-digit  drawing  numbering  scheme.  Table  2.8-1  summarizes  the  satellite’s  dimensions, 
mass,  and  inertial  properties.  Note  that  the  external  dimensions  in  the  Y  and  Z  directions  take 
into  account  the  thickness  of  bolt  heads  external  to  the  solar  panels.  When  these  are  considered, 
the  true  Y  and  Z  external  dimensions  still  adhere  to  UNP  volume  guidelines,  with  approximately 
3mm  in  margin.  Furthermore,  the  total  mass  estimate  comes  from  the  Master  Equipment  List 
(MEL),  which  accounts  for  several  items  not  included  in  the  CAD  model,  namely  the  wiring 
harness.  The  calculated  center  of  mass  is  relative  to  the  CASTOR  coordinate  frame,  and  does  not 
include  the  mass  of  the  wiring  harness.  The  subsequent  figure  depicts  the  CASTOR  satellite  in 
the  deployed  configuration. 

It  should  be  noted  that  the  current  dimensions  exceed  the  limits  imposed  by  UNP.  The  throat  of 
the  Xenon  tank  previously  extended  past  the  separation  interface  plane.  The  tank  section  was 
thereby  raised  to  prevent  this.  A  volume  waiver  is  currently  being  sought. 


Property 

Requirement 

Current  Estimate 

External  Dimensions  (x,y,z)  (cm) 

(60,  50,  50) 

(69.61,49.81,49.81) 

Mass  (kg) 

<50 

40.57  (45.86  margined) 

Center  of  Mass  (x,y,z)  (cm) 

(>-40,  <0.5,  <0.5) 

(-36.763,0.621,0.612) 

Moments  of  Inertia  (lx,  Iy,  Iz)  (kg*cmA2) 

N/A 

Ix  =  (0.991, -0.053, -0.123) 

Iy  =  (0.120,  0.763,0.635) 

Iz  =  (0.060,  -0.644,  0.762) 

TABLE  2.8-1:  CASTOR  STRUCTURAL  PROPERTIES 
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FIGURE  2.8-1:  CASTOR  DEPLOYED  CONFIGURATION 

Structure  Organization:  Major  Sub- Assemblies 

The  structure  of  the  satellite  is  centered  symmetrically  around  the  propellant  tank  in  the  stowed 
configuration.  The  thruster,  battery,  and  large  avionics  assembly  are  mounted  on  the  tank 
clamps.  This  configuration  keeps  the  most  massive  components  closest  to  satellite’s  strongest 
structures,  and  helps  to  ensure  that  the  satellite’s  center  of  mass  is  nearly  concentric  with  the  X- 
axis.  The  propellant  tank  is  cradled  by  three  tank  clamps  designed  to  transfer  loads  around  the 
tank  to  mitigate  structural  loading  on  the  pressure  vessel.  The  tank  clamps  connect  to  four 
trusses  clocked  at  90°  increments.  The  trusses  are  further  supported  by  eight  angle  braces 
spanning  the  diagonal  between  each  exterior  truss  edge.  Combined,  the  trusses  and  braces 
support  the  four  solar  panels  and  connect  the  satellite  to  the  ESPA  Lightband. 

CASTOR’S  structure  can  be  divided  into  4  primary  assemblies:  the  Tank  Section,  the  Truss 
Section,  the  Solar  Panel  Section,  and  the  Trans-Structure  Section.  This  organization  is  used  to 
determine  part  numbers  and  subassemblies  for  the  UCM.  These  subassemblies  keep  the  various 
components  grouped  by  section  and  reduce  the  number  of  single  components  used  in  the  master 
assembly. 

The  Tank  Section  is  comprised  of  the  centrally  located  Xenon  Tank  and  surrounding 
components.  Among  these  components  are  3  tank  clamps  that  cradle  the  tank,  2  tank  plates 
fastened  to  those  tank  clamps,  and  the  Thruster  Mounting  Assembly  that  supports  the  Diverging 
Cusped  Field  Thruster. 

Next,  the  four  trusses  that  connect  to  the  tank  clamps  and  components  mounted  to  them  make  up 
the  Truss  Section.  These  trusses  integrate  the  satellite  together  by  interfacing  with  components 
from  all  three  other  structural  sections.  Moreover,  the  trusses  serve  as  mounts  for  components 
from  non-structure  subsystems,  such  as  reaction  wheels,  a  patch  antenna,  the  plumbing  system, 


16.83  CASTOR  Design  Document 


Page  194 


November  18,  2010 


and  more.  With  the  exception  of  the  Small  Avionics  Box,  the  more  massive  components  - 
namely  the  Large  Avionics  Box  and  Battery  Box  -  are  mounted  to  the  tank  clamps,  to  reduce  the 
required  mass  of  the  trusses,  among  other  reasons. 

CASTOR  has  four  solar  panels:  two  deployable  and  two  body-fixed.  The  satellite  remains  in  a 
stowed  configuration  when  the  deployable  solar  panels  are  stowed  during  launch.  It  enters  the 
deployed  configuration  when  the  deployable  solar  panels  are  released  after  insertion  into  orbit. 
All  four  solar  panels  are  composites  of  aluminum  face  sheets  and  a  honeycomb  aluminum  core. 
Solar  cells  are  mounted  to  FR4  printed  circuit  board  sheets,  which  are  then  fixed  to  the  exterior 
face  of  the  panels  with  epoxy. 

Finally,  the  Trans-Structure  Section  includes  both  structural  brackets  and  non -structural  parts 
that  span  across  several  sub-assemblies.  Key  examples  of  such  non-structural  components 
include  the  plumbing  system  for  the  Xenon  tank  and  the  wiring  harness.  Among  the  structural 
brackets  are:  (1)  Solar  Panel  Braces,  which  both  provide  stiffness  between  the  trusses  and 
prevent  the  formation  of  a  drumhead  mode  in  the  center  of  the  solar  panels;  (2)  Lightband 
bracket,  which  interfaces  between  the  four  trusses  and  the  ESPA  mount;  and  (3)  solar  panel 
support  braces,  which  further  stiffen  the  solar  panels. 


2.8.3  INTERFACING  (E.  PETERS) 

The  components  shall  be  mounted  to  the  trusses  using  steel  bolts;  the  lengths  and  type  of  bolt 
shall  depend  on  the  component.  Tables  2.8-2  -  2.8-8  show  the  current  bolts  that  are  needed  and  a 
brief  description  of  relevant  information. 
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TABLE  2.8-2:  CURRENT  BOLT  INFORMATION  ADCS 


System 

Mount  To: 

# 

Bolt  Type 

Mounting 

Information 

Reaction  Wheel 

Truss 

12 

M3  x  3” 

There  are  3  wheels 
(one  on  truss  #1, 
one  on  truss  #4,  and 
one  on  the  X-face 
of  the  battery  box) 

Sun  Sensor 

Truss 

8 

2-56  x  y2” 

4  sun  sensors 
distributed  between 
trusses  1,  2,  and  3.  2 
bolts  and  1  pin  per 

sensor. 

4 

M2  alignment 
pins 

8 

10-24  x  1” 

GPS  Antenna 

Truss  1 

2 

10-24  x  1” 

Magnet  Bracket 

Bottom  Tank 
Clamp 

4 

10-24x3.5” 

Bolted  into  bottom 
tank  clamp 

Torque  Coils 

Braces/Trusses 

- 

- 

Held  in  place  with 
zip  ties 

in 

V 

Q 

< 


TABLE  2.8-3:  CURRENT  BOLT  INFORMATION  AVIONICS 


System 


Mount  To: 


# 


Bolt  Type 


Mounting 

Information 


C/3 

O 

•  pn 

a 

© 

< 


High-voltage 
avionics  assembly 


Tank 

Clamps 


1/4-20  x  5/8’ 


1/4-20x7/16” 


Shorter  bolts  for 
middle  hole  in 
top/bottom  clamps 


Low-voltage 
avionics  assembly 


Wiring  harness 
mounts 


1/4-20  x  5/8’ 


Truss  1 


Shorter  bolts  for 
middle  hole  in 
top/bottom  clamps 


TABLE  2.8-4:  CURRENT  BOLT  INFORMATION  COMMUNICATIONS 
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System 

Mount  To: 

# 

Bolt  Type 

Mounting 

Information 

Patch  Antenna 

Bracket 

Various 

6 

10-24  x  5/8” 

Face  +X  and  -X 
directions; 
cantilevered  off 
truss  4 

Patch  Antenna 

Various 

12 

8-32  x  5/8” 

Two  attached  to 
brackets,  one 
attached  to  Solar 

Panel  4 

Antenna  Splitter 

Truss  4 

4 

6-32  x  1” 
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TABLE  2.8-5:  CURRENT  BOLT  INFORMATION  PROPULSION 


System 

Mount  To: 

# 

Bolt  Type 

Mounting 

Information 

Xenon  Tank 

Tank 

Clamps 

- 

- 

No  bolts  into  tank; 
cradled  by  clamps 

Relief  Valve 

Truss  3 

2 

10-24  x  0.75” 

2  bolt  holes 
separated  by  0.75” 

Pressure  Regulator 

Truss  3 

2 

10-32x0.75” 

2  bolt  holes 
separated  by  0.75” 

Latching  Solenoid 

Truss  3 

2 

4-40  x  0.5” 

2  bolt  holes 
separated  by 
0.375” 

Flow  Controller 

Mounting 

Plate 

4 

4-40  x  0.75” 

2  flow  controllers 

Flow  Controller 
Mounting  Plate 

Truss  3 

4 

10-24  x  5/8” 

Mounted  to  top  of 
Truss  3 

Cathode  Heater 

Thruster 

Mounting 

Plate 

6 

4-40 

- 

Cathode  Keeper 

Thruster 

Mounting 

Plate 

3 

4-40 

- 

Anode 

Thruster 

Mounting 

Plate 

4 

8-40  x  5/8” 

- 
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TABLE  2.8-6:  CURRENT  BOLT  INFORMATION  POWER 


System 

Mount  To: 

# 

Bolt  Type 

Mounting 

Information 

Anode  Converter 

High- 

Voltage 

Avionics 

Box 

4 

4-40  x  0.75” 

Mounted  through 
bottom  of  box  into 

converter 

High- 


MPPT  .  .  .  4  10-24x5/8” 

Avionics 

Box 


Battery  Box 

Tank  Plate 

10 

4-40  x  0.5” 

" 

Tank  Plate 

Tank 

4 

1/4-20  x  5/8” 

Smaller  bolts  go 
into  middle  holes 

Clamps 

2 

1/4-20x7/16” 

of  clamps 

TABLE  2.8-7:  CURRENT  BOLT  INFORMATION  LAUNCH  VEHICLE 


System 

Mount  To: 

# 

Bolt  Type 

Mounting 

Information 

Lightband  Ring 

Lightband 

Brackets 

24 

1/4-28  x  1” 

Mounted  through 
bottom  of  ring  into 
brackets 

Thermal  Sensors 

Various 

- 

- 

20  thermal  sensors, 
all  attached  via 
thermal  adhesive 
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TABLE  2.8-8:  CURRENT  BOLT  INFORMATION  STRUCTURES 


System 

Mount  To: 

# 

Bolt  Type 

Mounting 

Information 

Tank  Clamps 

Trusses 

8 

3/8-16  x  1.5” 

8-32  bolts  for 
middle  tank  clamp 

4 

8-32  x  1.5” 

20  thermal  sensors, 

Solar  Arrays 

Trusses 

26 

10-24  x  0.5” 

all  attached  via 
thermal  adhesive 

DMB 

Truss  3 

4 

10-24  x  5/8” 

Truss  3 

Hinge 

Trusses 

8 

10-24  x  5/8” 

Trusses  1  and  4 

LY 

HMB 

Trusses 

8 

10-24  x  5/8” 

Trusses  1  and  4 

SPB  Bracket 

Trusses 

8 

10-24  x  5/8” 

2  on  each  truss 

SPB 

SPB 

Brackets 

16 

10-24  x  3/8” 

Flat-head  machine 

screws 

Spring  Hinge 

Spring 
Hinge  Plate 

16 

6-32x0.25” 

Flat-head  machine 

screws 

Spring  Hinge  Plate 

Trusses 

4 

6-32  x  5/8” 

Trusses  1  and  4 

SPRM 

Truss  1 

4 

10-24  x  1” 

- 

2.8.4  TANK  CLAMPS  (E.  PETERS) 

Three  centrally  located  tank  clamps  serve  (1)  to  integrate  the  entire  primary  structure,  and  (2)  to 
provide  an  interface  between  the  xenon  fuel  tank  and  the  primary  structure  by  cradling  the  tank. 
All  three  clamps  are  concentric  with  the  tank  and  the  X-Axis,  with  the  Bottom  Tank  Clamp 
located  the  farthest  in  the  +X  direction,  the  Top  Tank  Clamp  the  farthest  in  the  -X  direction,  and 
the  Middle  Tank  Clamp  in  between.  The  three  clamps  are  shown  integrated  with  other 
components  in  the  Tank  Section  in  Figure  2.8-2:  Tank  Section. 
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FIGURE  2.8-2:  TANK  SECTION 


The  tank  clamps  are  focal  components  within  the  satellite’s  primary  structure,  as  they  connect 
most  other  key  primary  structure  components  together.  All  three  clamps  interface  with  all  four 
trusses  and  both  tank  plates — on  which  the  majority  of  CASTOR’S  components  are  mounted.  In 
addition,  the  Thruster  Mounting  Assembly  is  attached  to  the  Top  Tank  Clamp.  The  Top  and 
Bottom  Tank  Clamps,  which  are  1”  thick,  are  fastened  to  the  trusses  with  3/8”  bolts  and  to  the 
tank  plates  with  1/4”  bolts,  whereas  the  A”  thick  Middle  Tank  Clamp  is  fastened  to  both  the 
trusses  and  the  tank  plates  with  #8  bolts. 

In  order  to  fully  constrain  the  Xenon  tank,  the  Top  and  Bottom  Tank  Clamps  have  concave 
curvature  to  match  the  shape  of  the  tank.  This  can  be  seen  in  Figures  2.8-6  and  2.8-7.  While  the 
Top  Tank  Clamp  is  a  single  piece,  the  Bottom  Tank  Clamp  is  a  two-piece  assembly  that  consists 
of  the  clamp  and  a  cap.  The  cap  contains  the  concave  surface,  and  is  bolted  to  the  clamp  after  the 
tank  is  inserted.  This  allows  the  tank  to  be  easily  inserted  or  removed  during  the  integration 
process.  The  Middle  Tank  Clamp  has  no  such  curvature,  but  rather  consists  of  two  halves  that 
can  be  tightened  together  to  increase  lateral  friction.  Strips  of  low-outgassing,  silicone  rubber 
[TBR]  will  be  included  between  the  tank  and  the  three  clamps  to  allow  for  minute  error  and 
prevent  damage  to  the  tank’s  surface. 
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FIGURE  2.8-6:  TOP  TANK  CLAMP 


2.8.5  SOLAR  PANEL  DEPLOYMENT  (E.  PETERS) 


Design  Overview 

Two  mechanisms  govern  solar  panel  deployment:  the  Solar  Panel  Release  Mechanism  (SPRM) 
and  the  Solar  Panel  Deployment  Mechanism  (SPDM).  While  the  SPRMs  control  when  the  solar 
panels  deploy,  the  SPDMs  affect  how  they  deploy,  in  addition  to  ensuring  that  the  satellite 
maintains  its  Deployed  Configuration  once  attained.  To  reduce  the  risk  of  premature  deployment, 
two  independent  SPRMs  will  be  employed  to  constrain  the  deploying  solar  panels.  There  are  also 
two  SPDMs,  but  each  SPDM  only  interfaces  with  a  single,  whereas  both  SPRMs  interface  with 
both  deploying  solar  panels. 
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Solar  Panel  Release  Mechanism  (SPRM) 

In  designing  the  Solar  Panel  Release  Mechanism,  the  following  factors  were  considered:  (1) 
striving  for  simplicity  to  maximize  the  probability  of  successful  solar  panel  deployment;  (2) 
lowering  mass  and  power  requirements  to  minimize  impact  on  the  mass  and  power  budgets;  (3) 
incorporating  a  reasonable  margin  for  error,  (4)  ease  of  manufacturing. 

Each  SPRM  is  restrained  by  a  linear  actuator.  Once  activated,  the  actuator  will  retract  its  pin, 
after  which  the  two  solar  panel  pins  attached  to  each  of  the  adjacent  solar  panels  will  be  released. 
Then,  with  the  help  of  the  Solar  Panel  Deployment  Mechanism,  the  solar  panels  will  be  able  to 
deploy.  This  SPRM  will  constrain  the  deploying  Solar  Panels  in  the  X,  Y,  and  Z  directions  at  two 
points.  During  launch,  these  rigid  constraints  serve  the  added  purpose  of  stiffening  the  solar 
panels,  increasing  the  vibration  resistance. 

The  SPRM  consists  of  the  following  components:  two  solar  panel  pins,  one  linear  actuator  and 
pin,  and  one  main  bracket  that  attaches  the  mechanism  to  the  primary  structure.  The  bracket  will 
be  made  of  several  1/4”  and  1/8”  thick  aluminum  extrusions  for  ease  of  fabrication.  The  two 
SPRMs  are  both  located  on  the  farthest  point  of  Truss  1  in  the  -Z  direction.  The  integrated 
SPRM  is  depicted  in  Figure  2.8-7. 


FIGURE  2.8-7:  SOLAR  PANEL  RELEASE  MECHANISM 


The  SPRM  Bracket  consists  of  4  stacked  aluminum  plates:  2  l/8”-pieces  in  the  middle  that 
constrain  each  of  the  solar  panel  pins  in  the  Y  and  Z  directions,  and  1/4”  and  1/8”  pieces  on  the 
top  and  bottom,  respectively,  that  (a)  constrain  the  solar  panel  pins  in  the  X  direction;  (b) 
constrain  the  actuator  pin  in  the  YZ  plane;  and  (c)  attach  the  mechanism  to  the  primary  structure. 
The  four  extrusions  are  bolted  together  with  three  bolts.  Manufacturing  the  bracket  out  of  four 
pieces  -  as  opposed  to  machining  the  bracket  from  a  single  piece  -  is  necessary  because  the  slots 
for  the  solar  panel  pins  have  a  complex  geometry  and  are  not  aligned  with  each  other,  and  hence 
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must  be  machined  individually.  The  second  iteration  of  the  SPRM  is  depicted  below  in  Figure 
2.8-8. 


FIGURE  2.8-8:  SPRM  BRACKET,  TOP  VIEW  (LEFT),  ISOMETRIC  VIEW  (RIGHT) 


The  Solar  Panel’s  path  of  release  has  a  radius  of  curvature  of  18.44”,  which  is  the  distance 
between  the  SPRM  and  the  pivots  of  the  hinges  about  which  the  Solar  Panels  rotate  when  they 
deploy.  The  solar  panel  pin,  therefore,  has  an  identical  curvature.  As  a  result,  due  to  machining 
considerations,  the  pin  is  uniformly  shaped  in  one  dimension.  The  pins  attach  to  the  solar  panels 
bolts  and  corresponding  inserts,  which  will  be  included  to  bolster  the  panel’s  structural  integrity 
(specifically,  that  of  its  honeycomb  core). 

Because  there  will  only  be  two  SPRMs  on  Truss  1,  each  SPRM  will  have  to  be  able  to  withstand 
50N  loading  from  each  solar  panel.  Static  analysis  has  shown  that  this  part  will  be  able  to 
withstand  50N  loading  with  a  lowest  factor  of  safety  (FOS)  of  6.44.  Whether  the  forces  of  both 
panels  were  applied  simultaneously  or  not  made  no  difference  in  the  results,  as  the  lowest  FOS 
occurs  in  the  solar  panel  pins  (which  are  independent  of  each  other),  not  the  solar  panel  bracket. 
These  calculations  assumed  that  the  force  was  normal  to  each  solar  panel;  any  other  direction 
would  result  in  a  higher  FOS  because  of  the  larger  cross-sectional  axial  area  of  the  solar  panel 
pins.  All  of  the  pieces  of  the  SPRM  bracket  were  approximated  as  one  component. 

Solar  Panel  Deployment  Mechanism  (SPDM) 

The  SPDMs  serve  three  primary  functions:  (1)  provide  the  force  necessary  to  rotate  the 
deploying  solar  panels  once  the  SPRMs  are  actuated;  (2)  provide  a  physical  mechanism  that 
stops  the  deploying  solar  panels  from  rotating  once  they  become  co-planar  with  Trusses  2  and  4; 
and  (3)  provide  a  limitation  on  the  deploying  solar  panels’  movement  after  they  are  deployed. 
The  current  SPDM  design  and  its  position  with  respect  to  the  primary  structure  is  illustrated 
below  in  Figure  2.8-3. 
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FIGURE  2.8-3:  SOLAR  PANEL  DEPLOYMENT  MECHANISM 


Originally,  Delrin  inserts  combined  with  strategically  placed  springs  formed  the  deployment 
mechanism.  After  the  SPRMs  released,  the  springs  would  begin  rotation,  until  45  degree  Delrin 
inserts  within  the  deploying  solar  panels  came  in  contact  with  the  side  faces  of  the  fixed  solar 
panels.  The  springs  would  continue  to  exert  a  force  after  this  deployed  state  was  reached,  in 
order  to  limit  further  motion  of  the  solar  panels.  This  design  was  abandoned  due  to 
manufacturing  problems  with  the  deploying  solar  panels,  mass  considerations,  and  doubts  about 
it  functionality. 

The  current  design  uses  spring-loaded  hinges  with  a  mechanical  stop.  The  spring-loaded  hinges 
are  of  a  smaller  plate  thickness  than  the  main  hinges  being  used.  A  mounting  plate  is  therefore 
required  to  keep  the  axis  of  rotation  of  the  spring-loaded  hinges  concentric  with  the  axis  of 
rotation  of  the  main  hinges.  The  interior  faces  of  the  mounting  plates  were  designed  to  contact 
each  other  once  the  rotation  reached  180  degrees,  and  prevent  further  rotation. 

It  can  be  assumed  that  attitude  adjustment  maneuvers  will  impart  small  disturbances  on  the 
deployed  solar  panels.  While  the  spring-loaded  hinges  provide  a  sufficient  moment  when  fully- 
compressed  to  successfully  deploy  the  panels,  they  do  not  provide  a  sufficient  restoring  moment 
for  small  (<  10  degrees)  displacement  from  the  deployed  configuration.  To  remedy  this,  a 
locking  mechanism  is  being  considered.  This  mechanism  will  utilize  tape  springs  mounted  to 
both  the  truss  and  the  solar  panel  such  that  the  convex  portion  points  away  from  the  solar  panel 
when  deployed.  In  this  orientation,  movement  of  the  panel  would  require  buckling  the  springs. 
This  mechanism  is  currently  being  prototyped. 


2.8.6  SOLAR  ARRAY  (L.  SHUMAKER) 


Requirements 

The  solar  array  and  accompanying  structure  must  meet  loading  and  frequency  requirements 
specified  by  UNP.  In  particular,  the  frequency  requirement — that  the  satellite  design  have  a  first 
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natural  frequency  of  100  Hz  or  more — is  of  concern  in  designing  the  solar  array.  In  addition,  the 
solar  array  must  maximize  area  available  for  power  generation  (requirement  of  the  Power  team) 
while  obeying  spatial  requirements  from  UNP  and  ideally  use  the  least  possible  amount  of  the 
UNP  mass  allocation  while  remaining  a  robust  and  reliable  structure.  While  the  stowed  design  of 
the  solar  panels  allows  for  some  power  generation,  proper  and  reliable  deployment  of  the  two 
deployable  panels  remains  a  primary  requirement  for  the  structure  since  power  generation  is  key 
to  mission  success. 


Design 

Current  architecture  of  the  satellite  places  the  propellant  tank  in  the  middle  of  the  structure,  with 
four  trusses  protruding  from  the  tank  clamps  in  an  X  shape.  The  solar  panels  are  attached  to  these 
trusses  in  their  stowed  positions  by  mounting  brackets  which  are  bolted  to  the  fins  and  bolted  to 
the  edges  of  each  solar  panel.  When  stowed,  the  satellite  presents  four  rectangular  solar  panels 
with  outward-facing  cells.  This  allows  some  solar  collection  before  the  panels  deploy.  When 
deployed,  the  edges  of  two  of  the  panels  (referred  to  as  the  deployable  panels)  release  from  one 
of  the  trusses  and  pivot  to  lie  parallel  to  the  trusses  while  remaining  connected  to  the  structure  by 
hinges,  as  shown  in  Figure  2.8-4. 


FIGURE  2.8-4:  SOLAR  PANELS  IN  DEPLOYED  CONFIGURATION 

To  address  the  requirement  that  the  satellite  fit  inside  a  50cm  x  50cm  x  60cm  box  when  in  the 
stowed  configuration  (with  the  two  deployable  solar  panels  stowed  against  the  trusses),  each  of 
the  four  solar  panels  must  actually  be  narrower  than  50cm  by  twice  the  thickness  of  a  panel. 
Currently,  the  solar  panels  are  0.25”  thick,  thus  the  maximum  panel  dimensions  are  60cm  x  43.2 
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cm.  These  dimensions  are  for  the  FR-4  on  aluminum  honeycomb  composite  on  which  the  solar 
cells  will  be  mounted,  and  include  all  area  for  solar  cells,  wiring,  and  space  necessary  to  attach 
solar  panel  mounting  brackets  to  each  panel  in  the  array. 

FR-4  on  aluminum  honeycomb  composite  has  been  chosen  as  the  substrate  material  over  either 
aluminum  sheet  on  aluminum  honeycomb  or  an  carbon  fiber  on  aluminum  honeycomb  because 
of  concerns  over  not  meeting  the  frequency  requirement,  conduction  between  solar  cells  through 
the  face  sheet  material,  and  exceeding  the  UNP  mass  limit.  The  FR-4  structures  performed  better 
than  the  carbon  fiber  and  aluminum  composite  during  vibration  testing  and  thermal  issues  can 
be  overcome  through  the  use  of  properly  specified  surface  treatments.  The  current  design  also 
offers  significant  mass  savings  over  the  other  two  options,  which  would  have  needed  additional 
PCB  layers. 

Previously,  both  deployable  solar  panels  included  a  chamfered  edge  that  served  as  a  stop  when 
they  deployed.  This  edge  was  the  side  of  a  Delrin  tab  that  protrudes  from  underneath  the  face 

^.ei^oa-a-atr-a-e-  -a 


sheet  as  shown  in 
Figure  2.8-5. 


16.83  CASTOR  Design  Document 


Page  207 


November  18,  2010 


FIGURE  2.8-5.  HONEYCOMB  AND  DELRIN  LAYUP  WITHIN  A  DEPLOYABLE  PANEL 

Since  the  inclusion  of  this  tab  introduced  manufacturing  problems  and  delaminated  during 
vibration  testing  -penalizing  the  satellite’s  fundamental  frequency — it  is  no  longer  included  in 
the  design.  Its  purpose,  to  ensure  deployment  at  the  proper  angle,  is  now  taken  care  of  by  the 
solar  panel  deployment  mechanisms  (SPDM),  and  thus  the  design  still  meets  requirements  and  is 
simpler  and  more  robust  than  previously. 


Panel  Connector  Arrangement 

Between  two  to  four  mounting  brackets  will  be  used  per  side  of  each  of  the  body-mounted 
panels.  Three  hinge  mounted  brackets  will  be  used  on  each  deployable  panel  as  well  as  two  solar 
panel  release  mechanisms  (SPRM).  These  brackets  fix  the  panels  to  the  trusses  (in  the  case  of  the 
two  body-mounted  panels)  and  to  the  hinges  and  to  the  trusses  in  the  stowed  configuration  (in  the 
case  of  the  two  deployable  panels).  Each  static  bracket  or  release  mechanism  is  attached  to  the 
panels  with  one  bolt.  Each  hinge  is  attached  to  the  panels  with  three  bolts.  Furthermore,  one 
SPDM  will  connect  each  deployable  panel  to  the  trusses  that  support  the  hinges  as  well.  Each 
bolt  hole  will  contain  two  flanged  inserts  (McMaster-Carr  part  number  93835A340)  placed  end 
to  end  that  will  help  clamp  the  face  sheets  onto  the  composite  substrate.  The  vertical  spacing 
between  bolt  holes  is  determined  by  the  optimal  placement  of  clamping  conditions  such  that  a 
panel  has  a  first  natural  frequency  of  over  100  Hz. 

Load  Considerations 

In  order  to  meet  the  criterion  that  the  satellite  structure  withstand  at  least  20  G  loading,  finite 
element  modeling  was  performed  for  a  solar  panel.  Each  panel  weighs  approximately  one 
kilogram,  so  under  launch  conditions,  the  panel  must  withstand  200  N.  A  plot  of  the  stress  tensor 
generated  by  Patran  and  Nastran  (FEM  software)  for  a  carbon  fiber  on  aluminum  honeycomb 
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panel  is  replicated  below  in  Figure  2.8-6.  The  white  areas  are  where  the  stress  is  zero,  and  the 
stress  ranges  up  to  492  Pa  at  the  bolt  holes.  In  the  light  blue  areas,  however,  the  stress  is  only  110 
Pa. 


FIGURE  2.8-6:  STRESS  TENSOR  UNDER  200N  LOADING  ON  THE  FACE  OF  A  PANEL  WITH  THREE 

ATTACHMENTS  PER  SIDE 

2 

The  yield  strength  of  carbon  fiber  sheet  ranges  from  289  MPa  upwards^  and  the  2%  yield  stress 

a 

of  aluminum  honeycomb  is  190  MPa  .  Clearly,  the  composite  panel  structure  will  be  able  to 
withstand  the  requisite  loads.  Stress  is  concentrated  at  the  connection  points  between  the  panel 
and  mounting  brackets,  so  the  bolts  will  be  appropriately  sized  to  transfer  loads  safely  from  the 
panels  to  the  primary  spacecraft  structure. 

Frequency  Considerations 

Of  more  concern  than  the  dynamic  loading  that  the  solar  panels  must  bear  is  their  natural 
frequency.  The  values  of  material  properties  and  dimensions  used  in  calculating  frequencies  are 
listed  in  Error!  Reference  source  not  found.. Error!  Reference  source  not  found.. 


Parameter 

Value 

Source/Notes 

Panel  dimensions 

48.6cm  x  60cm 

Constrained  by  UNP 

www. matweb.com.  Accessed:  11/18/09. 

3  Paik,  Jeom  Kee,  et  al.  “The  strength  characteristics  of  aluminum  honeycomb  sandwich  panels”. 
www.sciencedirect.com.  Accessed:  11/18/09. 
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Panel  thickness 

0.678cm 

Manufacturer’s  specifications 

Density 

210  kg/m3 

Experimentally  determined 

Mass  per  area  (gamma) 

14.2  kg/m2 

Experimentally  determined 

Modulus  of  Elasticity  of 
Aluminum 

1.3  GPa 

Manufacturer’s  specifications 

Modulus  of  Elasticity  of  Carbon 
Fiber 

lOGPa 

Manufacturer’s  specifications 

Combined  effective  modulus 

4.4  GPa 

Calculated 

Poisson’s  ratio  (nu) 

0.3 

Assumed 

TABLE  2.8-2:  SOLAR  PANEL  PROPERTIES 


Given  the  above  parameters  and  assuming  that  the  panel’s  frequency  can  be  modeled  as  a 
rectangular  pinned  plate  as  in  Figure  2.8-7,  the  frequency  may  be  determined  by  the  formula: 

f=  [^2/(2jia)]*[Eh3/  12(y(l  -v2)]172 

Where  E  is  the  modulus  of  elasticity,  y  is  the  mass  per  area,  h  is  the  panel  thickness,  v  is  the 
Poisson’s  ratio,  and  k2  is  a  tabulated  value  based  on  geometric  considerations4. 

Rectangular  Plate,  Comer  Supports 


FIGURE  2.8-7.  PLATE  MODEL 

With  this  model,  the  calculated  frequency  of  the  whole  panel  is  57  Hz.  This  model  does  neglect 
the  fact  that  the  plate  is  pinned  in  several  locations  on  each  side,  but  the  calculated  frequency  for 


44  Blevins,  Robert  D.  Formulas  for  Natural  Frequency  and  Mode  Shape.  Rrieger  Publishing  Company,  Malabar: 
2000.  p.  269. 
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one  bay  (the  rectangular  area  in  between  two  horizontal  sets  of  bolt  holes)  is  only  41  Hz.  If  the 
two  sides  of  length  a  in  Figure  2.8-7  are  considered  simply  supported  or  clamped  (corresponding 
to  reinforcing  the  panels  across  their  span  at  each  set  of  bolt  holes  with  horizontal  struts),  the 
calculated  frequencies  are  285  Hz  and  666  Hz,  respectively.  On  the  other  hand,  if  the  two  sides 
of  length  b  are  simply  supported  or  clamped  (corresponding  to  attaching  the  panels  to  the  fins 
along  their  length  rather  than  at  only  three  brackets),  the  corresponding  calculated  frequencies 
are  42  Hz  and  98  Hz.  Also,  if  the  solar  panels  were  made  thicker,  with  1.27cm  thick  honeycomb, 
the  calculated  frequency  for  the  original  pinned  model  is  101  Hz.  Several  design  options 
available  were  assessed;  additional  horizontal  aluminum  struts  and  clamped  vertical  edge 
scenarios  were  analyzed  with  Patran  and  Nastran.  Once  more  accurate  models  were  obtained  in 
this  fashion,  the  three  options — thicker  composite,  horizontal  struts,  or  clamped  edges — were 
assessed  from  a  mass  standpoint.  All  options  require  additional  mass;  however,  horizontal  struts 
also  require  some  redesign  of  the  solar  panel  brackets  and  release  mechanisms,  as  does  clamping 
the  edges  of  each  panel.  Clamped  edges  also  cut  into  available  surface  area  for  solar  cells.  These 
factors  were  taken  into  account,  and  the  final  solar  panel  design  calls  for  two  horizontal  struts  per 
panel,  as  well  as  solar  panels  supports  along  the  bottom  of  each  panel  for  additional  stiffening. 


Establishing  Vibration  Testing  Capability 

In  order  to  compose  a  recommendations  report  for  materials  selection,  the  structures  team  must 
take  into  consideration  the  thermal  properties  and  fundamental  frequencies  of  the 
materials/composites  under  consideration,  as  well  as  their  masses  and  certain  subjective  factors, 
such  as  ease  of  manufacture.  To  this  end,  it  is  necessary  to  design  a  low-cost  and  accessible 
vibration  testing  platform.  The  vibration  experiment  design  is  outlined  in  Figure  2.8-8. 
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sweep 

generator 


Produces  a  sinusoidal  voltage  that  sweeps  a  range 
of  frequencies 


Ensures  that  the  voltage  produced  does  not 
exceed  the  specifications  of  the  vibration  exciter 


vibration  exciter  which 
converts  voltage  into 
vibration 


test  specimen  with 
test  accelerometer 


mounting  bracket  with 
control  accelerometer 


reads  voltages 
from  the 
accelerometers 
and  outputs  data 
to  a  computer 


FIGURE  2.8-8:  VIBRATION  EQUIPMENT  SETUP 


Composite  Testing 

Three  sample  panels  were  fabricated  for  testing:  aluminum  face  sheets  on  %”  aluminum 
honeycomb,  carbon  fiber  face  sheets  on  %”  aluminum  honeycomb,  and  a  %”  thick  aluminum 
isogrid  with  four  bays.  The  purpose  of  testing  these  panels  was  threefold — these  were  three 
options  considered  for  the  solar  panel  design  of  CASTOR  and  the  testing  contributed  to  the  final 
choice  of  material,  (please  see  ),  experimental  results  could  be  compared  to  calculations  based  on 
tabulated  models  used  to  predict  the  modes  of  the  solar  panels  during  the  design  process  (specific 
calculations  for  the  carbon  fiber  composite  and  the  aluminum  composite  are  given  below),  and 
this  set  of  tests  also  allowed  reflection  on  the  design  of  the  vibration  table  setup  (results  given  in 
the  Analysis  section  below). 
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Calculations 


Rectangular  Plate,  Corner  Supports 


FIGURE  2.8-9:  PLATE  MODEL 

Formula  for  frequency  based  on  above  boundary  conditions5: 

1 

2 

,i  =  1,2,3...;;  =  1,2,3 


fii  = 


4 

27ra2 


Eh 3 


12(1-  v2) 


Formula  for  stiffness  factor  of  a  composite  plate  (Blevins): 
Eh 3  2 


12 


=  3*  ^  Ek*(dLi~  dl ) 


!c=0,l 


where  Ek  is  the  Young’s  modulus  of  each  material  in  the  composite  layup  and  dk  is  the  distance 
of  each  material  from  the  centerline  of  the  plate. 


TABLE  2.8-3:  CARBON  FIBER  PLATE  CHARACTERISTICS 


Parameter 

Value 

Source/Notes 

Plate  dimensions  (a  x  b) 

6”  x  3.25” 

Measured 

Geometric  constant,  A, 

9.29 

Approximation  based  on 
(a/b)  and  (Blevins,  283) 

Poisson’s  ratio,  v 

0.3 

Assumed 

5  Blevins,  Robert  D.  Formulas  for  Natural  Frequency  and  Mode  Shape.  Krieger  Publishing  Company,  Malabar: 
2000. 
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Mass  per  area,  y 

2.49  kg/m- 

Measured 

Stiffness  factor,  Eh3 

3.13  x  104 

Calculated  using 
manufacturer’s  material 
data  and  formula  listed 
above 

TABLE  2.8-4:  ALUMINUM  COMPOSITE  PLATE  CHARACTERISTICS 


Parameter 

Value 

Source/Notes 

Plate  dimensions  (a  x  b) 

6”  x  3.25” 

Measured 

Geometric  constant,  if 

9.29 

Approximation  based  on 
(a/b)  and  (Blevins,  283) 

Poisson’s  ratio,  v 

0.3 

Assumed 

Mass  per  area,  y 

3.97  kg/m3 

Measured 

Stiffness  factor  Eh3 

1.97  x  103 

Calculated  using 
manufacturer’s  material 
data  and  formula  listed 
above 

TABLE  2.8-5:  PREDICTED  FREQUENCIES 


Composite 

Predicted  first  frequency 

Carbon  fiber 

2.06  kHz 

Aluminum 

4.29  kHz 

Testing  Results 


Carbon  Fiber  Results 

There  was  some  sort  of  response  (amplitude  response  in  sample  data  versus  the  data  from  the 
control  accelerometer,  though  not  out  of  phase)  and  a  definite  1 80°  phase  shift  between  sample 
accelerometer  and  control  data  at  around  2.00  kHz  (as  predicted).  The  phase  shift  between  the 
driving  frequency  (as  reported  by  the  control)  and  the  output  frequency  (recorded  by  the  sample 
accelerometer)  occurs,  by  definition,  at  the  natural  frequency  of  the  sample. 

FIRST  MODE  (all  numbers  are  approximate):  581  Hz  (almost  three  to  four  times  amplification) 
Mode  at:  720  Hz 
Mode  at:  2.00  kHz 
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Aluminum  Composite  Results 

FIRST  MODE:  begins  somewhere  around  500  Hz,  PEAKS  at  860  Hz 
Mode  at:  1.43  kHz 
Mode  at:  3.99  kHz 


Aluminum  Isogrid  Results 

FIRST  MODE:  begins  somewhere  around  340  Hz,  PEAKS  around  530  Hz 

Mode  at:  770  Hz 

Mode  at:  1.87  kHz 

Mode  at:  2.06  kHz 

Mode  at:  3.32  kHz 


Analysis 

There  are  clear  differences  between  the  results  of  calculation  and  those  produced  by  testing  the 
sample  composites.  Before  sources  of  error  are  considered,  it  should  be  noted  that  the  boundary 
conditions  assumed  in  the  calculation  were  those  shown  in  Figure  2.8-7 — Error!  Reference 
source  not  found. — pinned  exactly  at  the  corners  of  the  plates — do  not  precisely  match  the 
actual  situation  where  bolts  were  used  to  clamp  the  plates  (with  the  bolt  holes  set  in  from  the 
corners  of  the  samples).  That  aside,  the  testing  shows  that  the  stiffest  sample  was  the  aluminum 
composite  and  that  both  it  and  the  carbon  fiber  composite  were  preferable  to  the  aluminum 
isogrid  in  this  respect.  For  the  actual  solar  panels,  however,  stringent  mass  limitations  make 
carbon  fiber  composites  more  attractive  than  aluminum. 

Sources  of  Error 

Several  sources  of  error  exist  in  the  testing  setup  itself;  specifically,  the  use  of  electrical  tape 
rather  than  a  rigid  standoff  between  the  sample  plate  and  the  mounting  bracket  means  that  the 
input  transfer  between  the  vibration  exciter  and  the  sample  being  testing  is  neither  perfect  nor 
necessarily  consistent.  This  may  have  some  bearing  on  the  accuracy  of  the  measured  modes. 
However,  the  tape  should  have  damped  out  some  of  the  input,  artificially  higher  modes,  so  it 
cannot  account  for  the  discrepancies  between  the  calculated  frequencies  and  those  returned  by 
the  tests.  Also,  the  panels  themselves  had  small  thermocouples  glued  to  them,  though  the  small 
size  of  these  devices  is  unlikely  to  affect  the  results  of  the  tests.  In  addition  to  the  thermocouples, 
the  carbon  fiber  composite  had  a  much  larger  diagnostic  device  affixed  to  one  edge  which 
conceivably  could  have  significantly  altered  the  results  for  this  plate.  In  terms  of  errors  present  in 
the  calculations,  the  effective  stiffness  factor  of  each  composite  plate  did  not  take  into  account 
the  material  properties  of  the  film  adhesive  in  between  the  face  sheets  and  the  honeycomb.  To 
check  if  this  factor  was  responsible  for  the  errors,  calculations  for  the  isogrid  (which  had  no 
adhesive)  should  be  compared  to  the  modes  found  empirically. 

Documentation  of  experiment  results  and  user’s  guide  for  the  testing  apparatus  is  also  compiled 
in  DD-SSL_vibration_testing_appendix.pdf  (located  in  3.10-Structures  on  the  fileshare). 
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Interfaces 

The  solar  arrays  interface  with  the  main  satellite  structure  through  the  solar  panel  mounting 
brackets,  hinge  mounted  brackets,  deployment  mechanisms,  and  release  mechanisms.  Most 
importantly,  since  they  generate  power  for  the  satellite,  the  arrays  also  interface  with  the  power 
and  propulsion  system. 


2.8.7  ESPA  MOUNT  (E.  PETERS) 


Requirements 

The  ESPA  ring  is  located  on  the  launch  vehicle,  under  the  primary  payload.  It  allows  secondary 
payloads  to  be  carried  by  the  vehicle  without  interfering  with  the  primary  payload.  Integration  of 
the  satellite  with  the  ESPA  ring  is  achieved  through  the  use  of  a  motorized  Lightband,  produced 
by  Planetary  Systems  Corporation.  One  side  of  the  Lightband  is  affixed  to  the  ESPA  ring.  The 
satellite  is  attached  to  the  other  side  of  the  Lightband.  After  reaching  orbit,  the  two  portions  of 
the  ring  detach,  and  the  satellite  is  released.  A  method  of  securing  the  satellite  to  this  structural 
device  is  necessary  to  ensure  successful  launch.  The  current  design  consists  of  four  quarter- 
circle  brackets  that  mount  between  the  four  trusses  and  interface  all  24  holes  of  the  Lightband.  A 
detailed  description  of  this  bracket  is  the  focus  of  this  section. 

Survival  of  launch  loads  was  of  primary  concern  in  the  design  of  this  part.  Solid  transfer  of 
loads  between  the  satellite  and  the  launch  vehicle  requires  a  rigid  connection  between  the 
satellite  and  the  Lightband.  Separation  of  the  satellite  from  the  Lightband  before  deployment  in 
space  would  be  considered  a  catastrophic  failure.  A  reliable  interface  between  the  satellite  and 
ESPA  Lightband  must  withstand  the  static  and  dynamic  loads  during  launch. 

Minimizing  component  mass,  while  still  withstanding  launch  loading  with  the  required  factor  of 
safety,  is  the  objective  of  the  Structures  team.  Ease  of  manufacture  and  assembly  is  also  a 
priority,  as  the  bolts  on  the  bracket  must  be  accessible  so  that  they  can  be  tightened  down  to 
torque-standards  for  both  testing  and  launch. 

UNP  judges  expressed  concern  that  previous  bracket  design  did  not  distribute  loads  evenly 
around  the  entire  Lightband  ring.  As  a  result,  the  design  was  modified  to  better  distribute  loads 
and  thus  assuage  concerns.  The  advantage  of  the  new  design  is  that  it  interfaces  all  24  holes  of 
the  Lightband,  as  opposed  to  the  former  design,  which  only  interfaced  16  holes. 

Before  a  new  design  is  accepted,  finite-element  modeling  (LEM)  is  used  to  predict  whether  the 
bracket  design  meets  structural  specifications.  If  models  show  that  the  bracket  design  is 
sufficient,  it  is  manufactured  and  subjected  to  static  and  vibration  testing  to  validate  the  model. 
Previous  modeling  suggested  that  the  initial  design  would  not  withstand  these  margined  loads. 
Analysis  of  the  current  design  has  shown  that  it  will  survive  launch  loads  with  the  required  safety 
margins. 

ESPA  Bracket  Design 
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The  Lightband  connection  brackets  serve  as  the  only  interface  between  the  launch  vehicle  and 
the  satellite.  Thus,  proper  design  of  these  brackets  is  critical  for  mission  success,  as  well  as 
launch  safety.  Prior  designs  of  this  part  were  insufficient  to  properly  transfer  loads  or  were  too 
massive;  hence  a  new  bracket  system  was  developed.  An  iterative  process  was  implemented  to 
factor  in  effects  analyzed  in  ANSYS  to  design  the  part.  Each  bracket  attaches  to  six  Lightband 
bolts,  and  has  two  connection  points  on  the  truss.  Bolts  to  the  Lightband  are  3/8-inch  in 
diameter,  to  allow  for  a  stiff  connection.  The  L-channel  design  helps  to  distribute  the  moment 
caused  by  the  cantilevered  satellite  and  provides  ample  access  space  for  a  torque- wrench  to 
tighten  the  bolts. 

Locations  of  the  brackets  on  the  satellite  are  shown  below  in  Ligure  2.8-10  in  the  red  circle. 


LIGURE  2.8-10:  LIGHTBAND  BRACKET  LOCATIONS  ON  SATELLITE 


The  current  design  partially  distributes  the  load  across  all  of  the  Lightband  holes.  Though  the 
load  concentration  is  still  greater  where  the  four  trusses  interface  with  the  brackets,  a  better 
distribution  across  the  entire  ring  has  still  been  achieved,  which  can  be  seen  in  Ligure  2.8-19 
below.  In  any  loading  configuration,  loads  in  the  Y-direction  or  Z-direction  will  be  balanced 
between  the  four  brackets.  PSC  (Planetary  Systems  Corporation),  showed  the  following  loading 
diagram  (Ligure  2.8-20)  Lightband  User’s  Guide. 
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A:  Static  Structural  (ANSYS) 

Equivalent  Stress 

Type:  Equivalent  (von-Mises)  Stress 
Unit:  Pa 
Time:  1 

7/15/2010  1:40  PM 


1.0631e8  Max 

9.4508e7 
8.2706e7 
7.0904e7 
5.9 102e7 
4.7299e7 
3.5497e7 
2.3695e7 
1. 1893e7 
91308  Min 


FIGURE  2.8-19:  STRESS  DISTRIBUTION  ON  NEW  LIGHTBAND  BRACKET 

Design  Considerations 

As  per  UNP  specifications,  the  Lightband  mounting  brackets  must  withstand  20-G  loading  with  a 
factor  of  safety  of  2.0  for  yield  and  2.6  for  ultimate.  The  brackets  must  also  interface  all  24  holes 
of  the  Lightband  ring. 

Due  to  mass  considerations,  and  the  ease  of  using  one  material,  aluminum  was  chosen  as  the 
base  material.  The  footprint  size  on  the  truss  was  increased  from  previous  designs,  to  allow  for 
the  use  of  3/8”- 1 6  bolts  rather  than  l/4”-20  bolts.  This  was  done  to  reduce  the  stresses  on  the 
truss-bracket  interface,  which  analysis  showed  to  be  the  area  of  highest  stress. 
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FIGURE  2.8-23:  CURRENT  BRACKET  DESIGN 


The  previous  bracket  design  was  unable  to  withstand  the  force  and  moment  produced  by  the 
satellite  under  20-G  loading  conditions  with  the  required  factor  of  safety,  and  needed  to  be 
redesigned.  Additionally,  the  full  bracket  assembly  only  interfaced  with  16  out  of  the  available 
24  holes  in  the  Lightband. 


Assumptions  and  Calculations 

Due  to  the  20-G  margined  launch  consideration,  each  bracket  must  support  a  force  of: 

20x(9.8^,)x(50Ag)_ 

4 

This  places  a  load  of  approximately  625N  on  each  truss  panel  bolt. 


Additionally,  the  moment  produced  by  the  satellite  under  this  loading  condition  must  be 
considered,  since  the  satellite  is  mounted  horizontally  to  the  ESPA  ring.  The  current  center  of 
mass  of  the  satellite  is  36.78  cm  above  the  Lightband  interface  plane.  Knowing  this,  the  moment 
imposed  on  each  mounting  bracket  by  the  satellite  under  20-G  loading  is: 


20  (9.8 "/,)  (50%)  (0.368  m) 
/  s 


=  902Nxm. 


A  simplification  assumed  that  all  forces  are  transferred  through  the  bolts  in  the  trusses.  In 
reality,  some  forces  are  transferred  by  surface  contact  of  the  panel  on  the  brackets  and  the  panel 
edge  on  the  Lightband  itself.  This  means  that  the  most  critical  axis  is  the  X-direction  (thrust 
vector)  where  these  bolts  are  the  sole  holding  mechanism  (no  surface  contact  forces). 


ANSYS  analysis  showed  that  the  new  bracket  design  exceeds  safety  requirements,  with  a 
minimum  factor  of  safety  of  2.64. 
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FIGURE  2.8-24:  Lightband  Analysis  Results 


2.8.8  LOADS  AND  MODES  (L.  SHUMAKER) 


Due  to  the  stringent  structural  requirements  placed  on  this  design,  it  is  necessary  to  submit  the 
spacecraft  to  a  battery  of  structural  testing.  This  testing  is  done  in  four  major  segments: 

•  individual  component  CAD  analysis 

•  individual  component  empirical  testing 

•  flight  modelCAD  analysis 

•  engineering  model  empirical  testing 

Individual  component  analysis  is  performed  on  all  structural  components  during  design  and 
redesign.  This  is  done  using  several  methods  so  as  to  provide  corroboration  from  one  result  to 
the  next.  The  primary  analysis  and  results  used  are  those  of  the  ANSYS  Workbench  Finite 
Element  Model.  Secondary  analyses  are  performed  using  hand  calculations,  basic  principles, 
and  results  obtained  from  literature  to  corroborate  with  finite  element  results.  These  numbers 
can  be  compared  to  the  FEM  in  order  to  determine  accurate  behavior  of  the  model.  ANSYS 
Workbench  was  chosen  to  enable  rapid  iteration  and  optimization  of  the  design  due  to  its 
superior  interface  with  Solidworks.  The  same  preparation  of  a  Solid  works  model  in  Patran  or 
ADINA  would  take  many  more  hours  than  Workbench,  which  automates  many  of  the  actions, 
while  still  allowing  the  interfaces  to  be  customized  as  the  user  wishes. 

The  individual  empirical  component  testing  is  performed  on  components  that  are  either  difficult 
to  model  or  on  components  that  are  particularly  susceptible  to  vibration  to  ensure  functionality 
when  on  orbit  and  to  serve  as  benchmarks  to  validate  the  finite  element  models  before  the  full 
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engineering  model  is  analyzed  and  tested.  This  testing  can  be  performed  in-house  with  vibration 
testing  platform  developed  for  the  project. 

The  engineering  model  analysis  is  performed  to  determine  how  the  components  interact  with 
each  other  and  what  additional  nonlinearities  arise  due  to  these  interactions.  Furthermore,  many 
of  the  boundary  conditions  assumed  in  the  component  analyses  do  not  flow  directly  to  their 
interfaces  with  other  components  in  the  full  engineering  model.  As  a  result,  this  analysis  is 
particularly  important  in  determining  if  the  spacecraft  itself  is  capable  of  meeting  structural 
design  requirements.  Furthermore,  it  is  highly  desirable  to  have  an  engineering  model  finite 
element  model  that  (1)  can  be  trusted  and  (2)  predicts  that  the  spacecraft  will  meet  design 
requirements  before  performing  any  integrated  structural  empirical  testing.  The  analysis  used  to 
verify  the  structural  model  is  described  further  in  the  Error!  Reference  source  not  found, 
section. 

The  empirical  testing  of  the  engineering  model  serves  as  the  final  structural  verification  of  all 
models  that  have  been  produced  and  consists  of  two  sets  of  tests:  vibration  testing,  which  was 
performed  at  the  MIT  Lincoln  Laboratory  shake  table,  and  static  testing,  which  is  performed  in- 
house  using  proof  masses.  These  tests  serve  to  not  only  prove  that  that  the  spacecraft  will  meet 
design  requirements,  but  also  to  validate  the  finite  element  model  and  determine  what 
modifications  and  additions  may  be  added  to  the  model  to  increase  fidelity  and  accuracy. 


Structural  Requirements 

There  are  two  key  structural  requirements  placed  on  the  satellite  by  the  University  Nanosatellite 
Program,  being  the  static  load  requirement  and  the  modal  requirement. 

•  The  satellite  shall  have  a  fundamental  frequency  above  100  Hz  given  a  fixed -base 
condition  at  the  Spacecraft  Interface  Plane 

•  The  satellite  must  be  able  to  withstand  limit  loads  of  20  Gs  independently  in  the  NS-6 
coordinate  system.  Accelerations  should  be  applied  the  spacecraft  center  of  mass. 

Furthermore,  a  factor  of  safety  of  2.0  must  be  used  for  yield  and  2.6  for  ultimate  failure. 
Mechanisms  must  be  designed  to  a  factor  of  2.0  in  analysis  and  tested  to  1.0. 


Finite  Element  Modeling 

Finite  modeling  is  performed  using  the  finite  element  solver  ANSYS  by  ANSYS  Corporation. 
Similarly,  the  pre/post  processor  used  is  ANSYS  Workbench  V12.0,  which  interfaces  directly 
with  the  solver.  It  should  be  noted  that  the  software  used  in  previous  design  iterations  was 
COSMOSWorks,  which  is  a  part  of  Solidworks,  which  is  the  CAD  tool  used.  However,  the 
change  was  made  due  to  licensing  issues  and  that  the  previous  software  provided  insufficient 
support  to  be  able  to  effectively  model  the  satellite.  Furthermore,  the  analysis  models  and  results 
are  stored  in  an  analysis  repository  that  is  separate  from  the  main  CASTOR  subversion  fileshare 
(https://planetx.mit.edu/mitsat_analysis). 
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As  such,  the  software  allows  the  user  to  import  solids  from  Solidworks,  define  appropriate 
materials,  define  and  create  the  finite  elements  and  meshes  to  be  used,  apply  loads  and  restraints, 
analyze,  and  view  results.  Two  types  of  analyses  are  used,  corresponding  to  the  design 
requirements  imposed.  ANSYS’s  Static  Structural  analysis  is  used  for  the  static  analyses  as  the 
standard  linear  solver  option  and  Modal  analysis  is  used  for  the  modal  analyses  as  the  standard 
normal  modes  solver  option.  Furthermore,  the  bodies  are  meshed  primarily  using  tetrahedral 
elements  (the  default  meshing  element),  however  hex  and  swept  elements  are  used  for  many 
elements  (such  as  solar  panels  and  other  shell-like  bodies).  Fortunately,  ANSYS  Workbench  has 
a  very  intelligent  meshing  algorithm,  which  is  able  to  determine  appropriate  mesh  type  based  on 
geometry.  Some  custom  modifications  were  necessary  in  order  to  decrease  the  number  of 
elements  and  degrees  of  freedom,  but  this  was  largely  limited  to  body  sizing  custom  parameters 
on  the  trusses,  plates,  and  many  of  the  brackets.  This  resulted  in  a  mesh  with  82,570  nodes  and 
30,153  elements,  which  was  just  below  the  limit  on  what  ANSYS  could  solve  with  its  memory 
allocation. 


Contact  regions  are  primarily  defined  using  “bonded”  contact  interfaces  so  as  to  scope  out  the 
need  for  bolt  interfaces  (to  reduce  the  problem  size  to  a  manageable  level).  The  one  exception  to 
this  rule  is  in  the  interface  between  the  solar  array  braces  and  the  solar  arrays,  where  a 
frictionless  boundary  condition  is  chosen.  This  is  in  an  attempt  to  simulate  the  actual  surface, 
where  the  panel  is  unable  to  move  in  one  direction  (is  supported  by  the  brace),  but  is  free  to 
move  in  the  other.  However,  the  results  discussed  below  were  generated  from  a  model  where  all 
contact  regions  were  defined  as  “bonded”  as  the  complexity  of  the  more  accurate  model 
exceeded  the  computing  power  currently  available  for  analysis.  In  the  next  cycle  of  analysis  and 
redesign  for  mass  optimization,  this  scenario  will  be  applied  to  a  simpler  model  to  identify 
reasonable  bounds  for  the  first  mode  of  the  satellite. 


Boundary  conditions  are  as  follows.  Six  degree  of  freedom  restraints  are  placed  on  the  bottom 
faces  of  the  lightband  brackets  to  simulate  attachment  to  the  Motorized  Lightband  and  fulfill  the 
UNP  requirement  of  determining  the  “fixed  base  natural  frequency”.  In  the  static  analyses, 
acceleration  loads  are  also  placed  in  each  of  the  orthogonal  directions  of  400  m/s',  to  simulate 
20Gs  at  a  safety  factor  of  2. 

Finite  element  model  point  masses  are  defined  as  in  Table  2.8-6Error!  Reference  source  not 
found. .Error!  Reference  source  not  found..  Locations  are  as  defined  in  the  CAD  model. 


Name 

Mass  (kg) 

Bottom  antenna  and  brackets 

0.0433 

Truss-mounted  antenna 

0.1568 

Magnet  and  bracket 

0.176 

Xenon  feed  system 

0.75 
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Relief  valves 

0.4 

Reaction  wheel  (3) 

0.225 

GPS  bracket 

0.00423 

GPS 

0.00414 

Anode 

2.277 

Avionics  components 

2.017 

Sun  sensor  (4) 

0.0491 

Imaging  assembly 

0.02674 

TABLE  2.8-6:  FEM  POINT  MASSES 

Engineering  Model  Finite  Element  Analysis 

The  finite  element  model  for  the  engineering  model  is,  in  general,  a  compilation  of: 

•  The  finite  element  models  of  the  primary  structure  components 

•  Simplified  versions  of  the  finite  element  models  of  secondary  structure  components 

•  Mass  models  of  non-structural  components,  namely  components  of  other  subsystems 
Creation  of  the  model  is  performed  as  follows. 

•  The  primary  structure  and  simplified  models  of  the  secondary  structure  is  assembled  and 
mated  in  Solidworks 

•  The  assembly  is  imported  directly  from  Solidworks  into  ANSYS  Workbench  using  the 
Workbench  interface  module 

•  Any  necessary  interface  conditions  are  modified  to  represent  the  accurate  interaction 
between  elements  in  the  FEM 

•  Loads  and  restraints  are  applied  to  the  model  to  represent  the  loading  conditions  applied 

•  Defining  material  properties  for  all  components 

•  Meshing  parameters  are  modified  as  necessary  to  allow  mesh  to  proceed 

•  Defining  point  masses  to  represent  any  non-structural  components 

•  Defining  analyses  and  any  desired  results 
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At  this  point,  the  model  is  submitted  for  analysis  and  debugged  as  necessary  until  it  is  believed  to 
be  reasonably  accurate.  Then,  the  geometry  is  modified  as  necessary  to  meet  design 
requirements. 

The  analysis  was  performed  on  the  simplified  version  of  the  satellite  so  as  to  determine  the 
baseline  frequency.  The  resulting  mode  is  shown  in  Figure  2.8-11 :  First  Modal  Analysis, 
showing  a  modal  deformation  plot  with  a  first  mode  of  approximately  131  Hz. 
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FIGURE  2.8-11:  FIRST  MODAL  ANALYSIS 


As  can  be  seen,  the  first  mode  is  a  solar  panel  mode.  This  mode  has  been  problematic  in  the 
past,  but  the  decision  to  manufacture  the  panel  composites  out  of  FR4  face  sheets  on  aluminum 
honeycomb  as  opposed  to  carbon  fiber  face  sheets  boosted  this  mode  to  above  the  UNP 
requirement  of  100  Hz.  The  current  design,  while  under  the  50  kg  total  mass  requirement,  could 
afford  improved  mass  savings.  Areas  which  will  be  modified  and  analyzed  again  for  mass 
optimization  are  listed  below: 

•  Re-organization  of  components  on  trusses  and  optimization  of  truss  speedholes 

•  Experimental  removal  of  a  solar  array  stiffener  to  the  bottom  of  each  of  the  solar  panels 
(originally  added  when  the  design  included  carbon  fiber  face  sheets) 

•  Reducing  the  height  and  thickness  of  various  component  brackets  that  are  currently 
conservatively  designed  in  order  to  meet  frequency  requirements  but  the  analysis 
indicates  that  they  affect  this  requirement  less  than  expected 


The  second  iteration  of  the  simplified  model,  wherein  SPRMs,  SPDMs,  and  HMBs  were  much 
simplified  in  order  to  reduce  the  amount  of  computation  needed  in  ANSYS  and  the  solar  panel 
brace  interface  was  modeled  as  frictionless,  showed  a  torsional  mode  in  the  trusses  with  a  first 
fundamental  frequency  of  approximately  85  Hz.  With  a  frictionless  interface  with  a  normal 
Lagrange  formulation,  the  frequency  remained  at  85  Hz  and  the  problematic  mode  was  still  in 
the  trusses  (ANSYS  defines  normal  Lagrange  as  follows:  enforces  zero  penetration  when  contact 
is  closed  making  use  of  a  Lagrange  multiplier  on  the  normal  direction  and  a  penalty  method  in 


16.83  CASTOR  Design  Document 


Page  224 


November  18,  2010 


the  tangential  direction).  Further  investigation  is  necessary  to  identify  how  to  best  model  the 
panel-brace  interface  and  then  optimization  will  begin  to  minimize  mass  usage  while  eliminating 
modal  issues  in  both  the  trusses  and  solar  panels. 

The  configuration  analyzed  has  the  safety  factors  and  stress  plots  as  shown  in  Figure  2.8-12 
through  Figure  2.8-13.  Since  this  analysis  was  for  40  G  loading,  for  20  G  loading  (the  UNP 
requirement),  the  factor  of  safety  is  twice  that  shown  in  the  image,  or  3  rather  than  1.5. 


0.000  0.250  0.500  (m) 

I 

0.125  0.375 


FIGURE  2.8-12:40  G  STATIC  LOADING  PERPENDICULAR  TO  THE  THRUST  AXIS  (REPRESENTATIVE  OF 

BOTH  Y-  AND  Z-DIRECTIONS) 
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FIGURE  2.8-13:  STATIC  LOADING  PARALLEL  TO  THE  THRUST  AXIS 

The  greatest  stress  occurred  in  the  comers  of  the  solar  panels,  as  can  be  seen  in  the  top  left. 
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FIGURE  2.8-14:  DEFORMATION  DUE  TO  STATIC  LOADING  PERPENDICULAR  TO  THE  THRUST  AXIS 

As  can  be  seen,  the  safety  factors  given  by  stress  analyses  in  three  different  dimensions  were 
about  3  for  loads  perpendicular  to  the  thrust  axis  (recall  that  the  plots  above  were  for  40  Gs 
loading,  which  is  twice  the  UNP  requirement,  and  thus  the  safety  factors  given  in  the  plots 
should  be  doubled).  The  final  image  demonstrates  the  total  deformation  expected  of  the  satellite 
structure,  with  a  maximum  deformation  in  the  solar  panels  of  approximately  1  mm. 
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Analysis  was  performed  separately  on  several  key  component  brackets  that  were  overdesigned, 
most  importantly  on  the  Lightband  brackets  that  attach  the  four  structural  trusses  to  the 
Lightband  interface.  Originally,  the  brackets  did  not  meet  the  factor  of  safety  requirements,  but 
appropriate  design  changes  were  made  to  address  this.  A  detailed  discussion  of  the  results  can  be 
found  under  2.8.7  ESPA  Mount. 

More  representative  of  the  other  components,  the  magnet  bracket  assembly  was  shown  to  be 
overdesigned  and  has  undergone  two  cycles  of  analysis.  Analysis  showed  that  the  bracket  was 
overdesigned,  and  that  its  mass  could  be  reduced  by  decreasing  the  thickness  of  the  support 
arms,  while  still  maintaining  a  factor  of  safety  greater  than  what  is  required.  Though  the  first 
fundamental  mode  of  the  new  design  decreased  from  over  1400  Hz  to  830  Hz,  this  is  still  well 
over  the  100  Hz  requirement.  The  new  design  still  has  a  factor  of  safety  greater  than  10.  Future 
revisions  may  include  a  material  switch  from  aluminum  to  Delrin,  for  greater  mass  reduction. 


The  Solar  Panel  Release  Mechanism  (SPRM)  and  solar  panel  deployment  mechanism  (SPDM) 
were  also  shown  to  be  overdesigned.  The  SPRM  currently  has  a  factor  of  safety  greater  than  10, 
while  the  SPDM  has  a  factor  of  safety  of  6.4.  These  designs  may  be  modified  in  the  future  to 
reduce  mass,  if  needed. 


Large  safety  factors  are  mostly  due  to  the  need  to  meet  frequency  requirements  and  are  thus  not 
considered  excessive  from  a  design  perspective.  Based  on  the  total  model’s  modal  and  static 
analysis  results  given  above,  this  design  is  deemed  acceptable  pending  future  analysis  and 
revision  based  on  CDR  feedback  to  increase  the  mass  margin  while  retaining  a  favorable  first 
mode  and  structural  integrity. 


Engineering  Model  Empirical  Testing 

Empirical  testing  of  the  engineering  model  is  performed  as  the  final  structural  verification  of  the 
satellite.  The  purpose  is  to  both  prove  that  the  physical  model  can  withstand  loads  and  to  verify 
the  fidelity  of  the  model.  As  mentioned  above,  this  is  done  in  two  phases:  static  testing  and 
vibration  testing. 

For  static  testing,  this  is  performed  by  mounting  the  model  of  the  satellite  to  the  strongback  in 
the  hanger  in  building  33  using  a  Lightband  interface  mockup.  Then,  loading  may  be  applied 
using  a  series  of  proof  masses  to  test  the  satellite  in  each  of  the  required  directions. 

Vibration  testing  is  performed  at  the  MIT  Lincoln  Laboratory  environmental  testing  facility.  It 
consists  of  a  series  of  tests  that  are  performed  in  the  order  specified  below  for  each  axis: 

1.  Low  Random  vibe  to  identify  modes  and  points  of  resonance 

2.  Sine  sweep  test  to  verify  the  natural  frequency 

3.  Sine  burst  test  to  verify  structural  strength 

4.  Sine  sweep  test  to  re-verify  the  natural  frequency 

5.  High  Random  vibration  test 
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6.  Sine  sweep  test  to  re-verify  the  natural  frequency 

7.  Shock  test 

8.  Sine  sweep  test  to  re-verify  the  natural  frequency 

In  previous  test  campaigns,  the  shock  testing  (7)  had  never  been  performed  due  to  uncertainty  in 
what  loads  should  be  applied  and  since  the  table  at  the  facility  was  incapable  of  providing  the 
shock  levels  as  specified  in  the  User’s  Guide.  Further  information  regarding  vibration  testing 
procedures  may  be  found  in  section  2.4. 1.2  of  the  fileshare. 


2.9  GROUND  SYSTEM  EQUIPMENT 


2.9.1  GSE  OVERVIEW  (D.  ROCKWELL) 

The  ground  support  equipment  section  will  describe  the  requirements  of  mechanical  and 
electrical  ground  support  equipment,  detail  the  conceptual  designs  made  to  fulfill  some,  not  all 
requirements,  and  will  also  briefly  make  references  to  the  design  constraints  made  by  the  limited 
availability  of  interfaces  on  the  satellite  for  ground  support  equipment.  The  ground  support 
equipment  will  be  used  for  transportation,  handling,  and  preparation  of  CASTOR  at  testing  and 
launch  sites,  and  is  still  in  a  conceptual  design  phase  as  other  subsystems  finalize  their  design. 


2.9.2  GSE  REQUIREMENT  (D.  ROCKWELL) 


The  shipping  container  shall: 

•  Contain  the  entire  satellite  or  satellite  stack 

•  Maintain  class  100,000  clean  conditions 

•  Provide  ESD  protection  to  the  satellite 

•  Have  a  means  for  grounding  the  container  from  an  external  grounding  point  before 
opening  container 

•  Enable  shipping  both  with  and  without  the  PSC  Lightband  integrated  to  CASTOR. 

•  Measure  the  shock  environment  experienced  by  the  satellite  during  shipping  through  the 
use  of  shock  sensors  in  all  3  axes.  Approved  shock  sensor  styles  are  ball  and  spring  or 
data-logger  type  shock  sensors,  sticker-type  shock  sensors  are  not  allowed.  Shock  sensors 
shall  be  placed  on  the  primary  mounting  plate/interface  to  the  satellite  so  as  to  accurately 
measure  the  shock  as  experienced  by  the  satellite 

It  is  also  recommended  that  the  shipping  container: 

•  Separate  into  two  pieces  at  the  interface  plane  between  the  satellite  and  the  container.  The 
intent  here  is  to  allow  easy  access  to  the  bolts  that  mate  the  satellite  and  the  container. 

•  The  shipping  container  should  incorporate  full  height  posts  that  are  affixed  to  the  outside 
corners  of  the  interface  plate.  These  corner  posts  protect  the  satellite  from  the  lid  while 
opening  and  closing 

•  Incorporate  a  shock  isolation  system,  usually  between  the  plate  on  which  the  satellite  is 
mounted  and  the  box. 

•  Incorporate  means  for  pressure  equalization  during  shipment  (significant  bowing  of 
container  walls  can  occur  due  to  differential  pressure) 
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•  48  point  bolt  circle  for  the  15"  Lightband.  Doubling  the  Lightband  interface  bolt  circle 
allows  for  flexibility  during  installation  of  satellite  in  the  container.  It  resolves  clocking 
issues. 

•  Have  wheels  for  ease  of  movement 

•  Incorporate  means  of  restraining  motion  of  container,  through  locking  wheels, 
retractable  wheels,  etc. 

•  Pallet  jack/fork  lift  compatible 

•  Handles  for  lifting  by  hand 

•  The  shipping  container  can  be  used  as  a  display  case 

Mechanical  Ground  Support  Equipment  (MGSE)  shall: 

•  Consist  of  a  lifting  harnesses  that  shall  be  designed  to  lift  CASTOR  from  a  single  point 
above  its  center  of  gravity,  in  every  orientation  except  upside  down  (+X,  -X,  +Y,  -Y,  +Z, 
and  not  -Z).  Lifting  equipment  shall  be  designed  such  that  it  will  not  contact  the 
Lightband  during  integration  and  ground  handling  operations. 

•  Consist  of  tabletop  MGSE  stands  that  must  be  able  to  support  CASTOR  with,  without, 
and  with  only  half  of  the  Lightband. 

•  Be  designed  using  a  factor  of  safety  of  5.0  for  ultimate  failure,  and  be  proof  loaded  to 
twice  the  design  load. 

•  Meet  all  requirements  for  flight  hardware  as  prescribed  in  KHB  1700. 7C,  if  it  shall 
remain  attached  to  CASTOR  for  flight. 

Electrical  Ground  Support  Equipment  (EGSE)  shall  perform  the  following  functions: 

•  Battery  charging  and  discharging  while  satellite  is  inhibited. 

•  Inhibit  actuation  (inhibit/enable  satellite). 

•  Power  satellite  while  satellite  is  inhibited. 

•  Support  functional  testing  of  satellite,  including  subsystem  level  and  full  "day  in  the  life" 
testing 

EGSE  will  also  meet  the  following  requirements: 

•  EGSE  shall  be  self  contained  and  portable. 

•  EGSE  shall  be  capable  of  command  and  control  of  the  satellite  without  free  radiation  of 
RF  energy,  i.e.  through  harnessing  and/or  with  RF  hats. 

•  EGSE  shall  also  be  capable  of  command  and  control  of  the  satellite  through  radios  and 
RF.  (Note  that  antenna  hats  satisfy  both  of  these  requirements.)  Both  communications 
channels  must  be  available. 

•  Functional  testing  after  integration  to  the  launch  vehicle  must  be  performed  without  free 
radiation  of  RF  energy. 

•  Battery  charging  equipment  in  the  EGSE  shall  be  current  limited  by  design  and  shall 
provide  monitoring  and  protection  to  prevent  battery  damage  or  failure. 

•  The  ability  to  discharge  the  battery  without  enabling  the  satellite  bus/loads  is  required, 
i.e.  through  resistors  contained  in  the  EGSE. 

•  A  main  power  switch  shall  be  provided,  with  indicator  light. 
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•  All  switches  or  buttons  shall  be  clearly  labeled. 

•  Separation  between  switches/buttons  shall  be  sufficient  to  avoid  accidental  actuation. 

•  Switches  shall  include  covers,  with  an  automatic-off  feature,  such  that  when  the  cover  is 
closed  the  switch  is  in  the  off  position. 

•  Circuit  protection  (fuses  or  circuit  breakers)  shall  be  installed  on  primary  circuits,  on  the 
load  (not  ground/return)  lines. 

•  Circuit  protection  devices  shall  be  readily  accessible  for  inspection,  reset,  or  replacement. 

•  Circuit  breaker  trips  and  fuse  blows  shall  be  readily  detectable  by  visual  inspection. 

•  Circuit  protection  shall  be  clearly  marked  with  voltage  present  and  rated  amperage. 

•  All  wiring  shall  be  copper  and  contact  with  dissimilar  metals  shall  be  avoided.  Aluminum 
wire  shall  not  be  used. 

•  Connectors  used  in  the  harnessing  between  the  satellite  and  the  EGSE  shall  be  scoop- 
proof. 

•  EGSE  shall  use  standard  120  V,  60  Hz,  3  prong  "household"  power,  preferably  through  a 
single  plug. 

•  If  batteries  are  included  as  part  of  the  EGSE,  polarity  of  battery  terminals  shall  be  clearly 
marked  and  ventilation  shall  be  provided  to  ensure  concentrations  of  vapor  do  not  reach 
25%  of  the  lower  explosion  limit. 

•  Equipment  shall  be  designed,  fabricated,  inspected,  and  tested  in  accordance  with  NFPA 
70. 

•  All  electrical  ground  support  equipment  (EGSE)  shall  meet  the  safety  requirements  of 
KHB  1700.7C  and  AFSPC  91-710  Vol  3  Sec  14.2. 

•  EGSE  components  and/or  interfaces  that  remain  attached  to  CASTOR  for  flight  must 
meet  all  requirements  for  flight  hardware. 

It  is  also  recommended  that  EGSE: 

•  Should  support  discharge  and  charge  state  verification  of  individual  cells. 

•  Should  be  designed  with  fuses  and  diode  protection  to  ensure  that  failures  in  ground 
support  equipment  or  procedural  mistakes  will  not  damage  CASTOR’S  hardware  or  cause 
other  hazardous  conditions. 

•  Should  not  have  connectors  with  exposed  pins.  This  applies  to  both  the  EGSE  itself  and 
the  flight  hardware. 


2.9.3  SHIPPING  CONTAINER  (L.  MCCARTHY) 

The  shipping  container  will  house  CASTOR  during  transport.  Along  with  all  other  MGSE,  it 
will  maintain  a  factor  of  safety  of  5.0  for  ultimate  failure.  It  will  be  approximately  95  cm  x  95 
cm  x  1 10  cm  in  size,  and  will  provide  a  space  of  approximately  90  cm  x  90  cm  x  95  cm  in  which 
to  house  the  50  cm  x  50  cm  x  60  cm  CASTOR.  The  extra  space  ensures  accessibility  to  the 
satellite,  and  provides  space  for  environmental  monitors,  shock  sensors,  MGSE,  EGSE,  and 
harness  equipment. 
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FIGURE  2.9-1  SHIPPING  CONTAINER  OPEN  CONFIGURATION 


FIGURE  2.9-2SHIPPING  CONTAINER  CLOSED  CONFIGURATION 


A  High  Efficiency  Particulate  Air  (HEPA)  filter  will  be  installed  to  maintain  class  100,000  clean 
conditions.  Environmental  monitors  will  confirm  these  conditions  by  recording  temperature, 
humidity,  and  air  pressure.  Shock  isolating  feet  will  also  be  incorporated,  and  shock  sensors  will 
determine  the  amount  of  stress  that  has  been  exerted  on  the  satellite  during  transport.  Grounding 
points  will  be  reachable  from  all  sides  to  protect  against  electrostatic  discharge  (ESD). 
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FIGURE  2.9-3:  FILTERED  VENT,  GROUND  AND  JACK  POINT 


The  shipping  container  will  also  be  pallet  jack/forklift  compatible.  Lifting  handles  at  the  top  can 
be  accessed  by  a  crane,  or  used  to  lift  the  container  by  hand.  Wheels  may  be  installed  for  ease  of 
mobility  along  the  ground. 


FIGURE  2.9-4:  PALLET  JACK/FORKLIFT  SOCKETS 


2.9.4  LIFTING  HARNESS  (D. ROCKWELL) 

The  lifting  harness  will  consist  of  four  top  lifting  harness  clamps,  four  bottom  lifting  harness 
clamps  (  of  similar  design  as  the  top  lifting  harness  clamps),  HT  Series  Aluminum  framing, 
joining  strips,  and  corner  brackets,  plexiglass  or  acrylic  sheet,  24-  %”  eyebolts  with  shoulders,  8- 
'/f’shoulder  bolts  with  an  aluminum  wire  pulley  system. 

The  lifting  harness  clamps  shown  in  (Figure  2.9-5:  Lifting  Harness  Clamp)  will  engage  the  four 
trusses  of  the  satellite.  The  lifting  harness  clamps  will  be  attached  to  the  trusses  shown  in  (Figure 
2.9-6:  Lifting  Harness  Clamp  with  satellite  and  Braced  structure)  with  8-  VC’shoulder  bolts 
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shown  in  (Figure  2.9-8).  The  lifting  harness  clamp  will  be  attached  to  the  braced  structure 
constructed  of  HT  Series  aluminum  the  structure  will  be  54  cm  x  54  cm  x  64  cm  modeled  in 
(Figure  2. 9-6) with  16  of  the  24-  Vi”  eyebolts  with  shoulders  shown  in  (Figure  2.9-8).  HT  Series 
aluminum  framing  was  chosen  to  minimize  the  need  for  welding  and  make  assembly  and 
disassembly  much  easier  for  this  frame.  The  lifting  harness  attach  points  that  will  be  used  for 
lifting  will  be  the  eyebolts  jutting  out  of  the  framed  structure  and  the  top/bottom  of  the  lifting 
harness  clamps.  The  number  of  eyebolts  ensures  that  there  are  at  least  8  eyebolts  pointing  in  all  3 
axial  directions.  The  aluminum  wiring  will  be  threaded  through  the  eyebolt  and  connect  to  an  as 
of  yet  unspecified  pulley  system.  The  framing  will  also  have  plexiglass  or  plastic  acrylic  sheet 
covering  to  protect  the  satellite’s  solar  panels. 


Eyebolts  Threaded 
Holes  and 
Interface  for  the 
Braced  Structure 


1/4”  shoulder  bolt 
insert  and  interface 
point  for  Trusses 

FIGURE  2.9-5:  LIFTING  HARNESS  CLAMP 
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FIGURE  2.9-6:  LIFTING  HARNESS  CLAMP  WITH  SATELLITE  AND  BRACED  STRUCTURE 


FIGURE  2.9-7:  HT  SERIES  ALUMINUM  FRAMING,  JOINING  STRIPS,  AND  CORNER  BRACKETS 
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2.9.5  EGSE  (D.  AINGE) 

To  minimize  the  complexity  of  the  EGSE,  our  design  will  utilize  as  few  in-house  products  as 
possible.  The  main  components  of  this  system  are  the  inhibitory  controls  and  the  battery  charger; 
good  off-the-shelf  solutions  already  exist  for  these  components.  Because  the  EGSE  will  be 
powered  with  a  single  household  three-prong  plug,  power  usage  is  not  a  concern.  AC/DC 
converters  will  be  implemented  to  allow  us  to  use  an  identical  charging  circuit  as  on-board  the 
satellite,  again  minimizing  complexity  and  risk.  Circuit  protection  will  be  used  on  the  AC  line 
coming  into  the  EGSE,  as  well  as  on  the  DC  line  headed  to  CASTOR  to  prevent  damages  from 
any  accidental  loads  in  either  direction. 


2.10  THERMAL  (W.PINO  &  A.ESPITIA) 


2.10.1  THERMAL  SYSTEM  OVERVIEW  (W.  PINO) 


The  thermal  section  of  the  design  document  describes  the  thermal  control  techniques  that 
are  used  on  the  satellite,  the  requirements  that  must  be  met,  the  methods  that  have  been  used  to 
analyze  the  system,  and  the  interfaces  that  exist  between  the  various  systems  that  are  affected  by 
the  thermal  design.  Thermal  control  is  essential  in  order  to  secure  the  performance  of  all 
components  on  the  satellite  during  the  various  mission  phases.  The  CASTOR  thermal  system 
includes  the  design  and  implementation  of  thermal  control  as  well  as  the  necessary  hardware.  To 
measure  temperatures,  there  are  20  analog  thermal  sensing  devices  on  the  satellite.  Of  those  20, 
14  are  temperature  sensors  and  6  are  thermocouples. 

There  are  several  methods  of  implementing  thermal  control.  The  CASTOR  satellite 
makes  use  of  passive  thermal  control  by  implementing  a  reflective  surface  coat.  After  studying 
the  results  from  the  thermal  analysis  described  in  the  modeling  approach  section,  it  was 
determined  that  Alodine  should  be  applied  to  all  the  aluminum  surfaces  and  that  Z93  should  be 
applied  on  the  back  of  the  panels  and  on  the  engine.  Z93  is  a  type  of  white  paint  that  has  a  low 
absorptive  coefficient  and  can  reflect  the  short  wavelength  infrared  light  emitted  by  the  sun.  The 
paint  also  has  a  high  emissivity  factor  and  can  expel  longer  wavelength  radiation  such  as  heat 
emitted  by  components  onboard  the  satellite.  The  use  of  these  materials  allows  the  satellite  to 
stay  within  desired  temperature  ranges  for  optimal  functionality. 


2.10.2  THERMAL  SYSTEM  REQUIREMENTS  (W.  PINO) 

The  thermal  system  team  is  required  to  provide  adequate  thermal  control  for  the  satellite 
for  all  stages  of  the  mission.  This  includes  a  range  of  altitudes  within  low  earth  orbit  as  well  as  a 
range  of  incidence  angles.  Thermal  models  of  the  satellite  must  also  be  presented  to  the  AFRL. 
There  are  temperature  limit  requirements  that  must  be  satisfied.  The  calculated  temperature 
ranges  for  each  component  must  fall  within  those  requirements.  It  is  necessary  to  include 
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operational  temperatures  ranges  that  span  temperatures  where  the  component  can  be  turned  on 
and  used.  Additionally,  survival  temperatures  ranges  must  be  provided.  These  output  values  for 
temperature  ranges  span  temperatures  that  the  component  can  endure  without  suffering  damages 
when  it  is  turned  off. 


TABLE  2.10-1:  TEMPERATURE  LIMIT  REQUIREMENTS 


Component 

Operating 
Range  °C 

Survival 
Range  °C 

Component 

Operating 
Range  °C 

Survival 
Range  °C 

NiCad 

0  to  70 

-20  to  75 

Camera 

-20  to  60 

-35  to  85 

MPPT 

-40  to  60 

-45  to  85 

Reaction 

Wheels 

-20  to  60 

-35  to  70 

PDU 

-55  to  100 

-65  to  110 

GPS 

-20  to  50 

-30  to  60 

PPU 

-45  to  85 

-45  to  90 

DCFT 

0  to  200 

-50  to  300 

MEMS  IMU 

-40  to  85 

-55  to  85 

Xenon  Gas 

0  to  127 

-50  to  127 

As  part  of  the  requirements,  it  is  necessary  to  provide  a  table  listing  the  thermophysical 
properties  of  all  the  materials  that  are  used  on  the  satellite.  The  following  table  lists  the  name  of 
the  material,  the  conductivity  (W/mm/K),  the  density  (kg/mmA3),  and  the  specific  heat  (J/kg/K) 
in  units  compatible  with  the  way  the  Thermal  Desktop  program  accepts  inputs. 

TABLE  2.10-2:  TABLE  OF  THERMOPHYSICAL  PROPERTIES 


Material  Name 

Conductivity  (W/mm/K) 

Density  (kg/mmA3) 

Specific  Heat  (J/kg/K) 

50%  Alum  6061-T6 

0.001 

1.36E-06 

1 

Air 

2.57E-05 

1.21E-09 

1.005 

Aluminum 

0.22 

2.71E-06 

896 

Aluminum  6061 

0.1679 

2.77E-06 

1256 

Aluminum  Alloy  606 1 

0.12134 

2.74E-06 

795 

Black  Plastic 

0.00023 

1.25E-06 

1930 

Carbon  Composite 

0.0002 

1.49E-06 

1880 

Chip 

0 

2.00E-06 

837.32 

Copper  Alloy 

0.388 

8.93E-06 

385 

Copper  Cl 9400 

0.26 

8.86E-06 

385 

Fr4  2oz  Copper 

0.0177 

1.91E-06 

600 

Glass 

0.002 

2.40E-06 

840 

Gold 

0.318 

1.89E-05 

130 

Lead 

0.035 

1.14E-05 

130 

Ml 

0.001 

2.59E-13 

1 

16.83  CASTOR  Design  Document 


Page  236 


November  18,  2010 


Magnesium 

0.15062 

1.74E-06 

1004 

ML1 

0.001 

1.00E-09 

0 

Silicon  Solar  Cells 

0.025 

2.33E-06 

712 

Stainless  Steel  316 

0.01626 

8.03E-06 

502.1 

Stainless  Steel,  AISI  301 

0.001 

7.92E-06 

1 

Water 

0.0006 

1.00E-06 

4200 

Xenon  Gas 

5.65E-06 

5.89E-09 

158.32 

TABLE  2.10-3:  TABLE  OF  OPTICAL  PROPERTIES 


Material  Name 

Solar 

Absorptivity 

IR  Emission 

A/E 

Aluminum  (anodized) 

0.140 

0.840 

0.167 

Aluminum  (polished) 

0.090 

0.030 

3.000 

Aluminum  (quarts  overcoated) 

0.110 

0.370 

0.297 

Aluminum  Alodine 

0.230 

0.030 

7.667 

Aluminum  Foil 

0.150 

0.050 

3.000 

Aluminum  (heavily  oxidized) 

0.130 

0.300 

0.433 

Anodize  Black 

0.880 

0.880 

1.000 

Black  Plastic 

0.250 

0.850 

1.129 

Brass 

0.550 

0.525 

0.476 

Copper  Foil  Tape 

0.960 

0.040 

13.750 

Delrin  Black  Tape 

0.250 

0.870 

1.103 

Dull  Brass,  Copper,  Steel,  Alumi 

0.550 

0.250 

2.100 

FR4 

0.960 

0.800 

1.200 

Gold  (highly  polished) 

0.090 

0.030 

3.000 

Graphite  Epoxy 

0.930 

0.850 

1.094 

Kapton  Film 

0.340 

0.550 

0.618 

Metal,  plated  nickel  oxide 

0.920 

0.080 

11.500 

MLI  (inner  surface) 

0.000 

0.950 

0.000 

MLI(outer  surface) 

0.380 

0.850 

0.447 

Opal  Glass 

0.280 

0.870 

0.322 

Silver  (highly  polished) 

0.075 

0.025 

3.000 

Solar  Cells 

0.850 

0.850 

1.000 

Tedlar  Black 

0.940 

0.900 

1.044 

Tedlar  White 

0.390 

0.870 

0.448 

Teflon  (silver,  5mil) 

0.080 

0.810 

0.099 

Xenon  Gas 

0.250 

0.250 

1.000 

Zerlauts  S-13G  White  Paint 

0.200 

0.900 

0.222 

Zerlauts  Z-93  White  Paint 

0.170 

0.920 

0.185 

2.10.3  THERMAL  MODELING  APPROACH  (W.  PINO) 
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There  are  three  facets  to  the  modeling  approach  used  on  the  CASTOR  satellite.  The  first  one 
involves  hand  calculations  that  make  use  of  the  governing  equations  that  affect  the  system.  The 
hand  calculations  are  used  to  solve  for  the  resulting  temperatures  of  the  satellite  components.  In 
order  to  capture  the  full  behavior  of  the  system,  all  phases  of  the  mission  were  analyzed.  This 
includes  polar  orbit  configurations,  where  the  satellite  experiences  the  most  extreme  hot  case  due 
to  continuous  sun  exposure  as  well  as  equatorial  orbit  configurations,  where  the  satellite  faces 
the  sun  for  only  a  portion  of  the  orbit.  The  mathematical  model  also  includes  the  effect  of 
reflected  sunlight  from  the  earth,  or  albedo,  and  the  effect  of  sunlight  absorbed  by  the  earth  that 
is  then  emitted  as  infrared  radiation.  These  calculations  were  written  into  a  MATLAB  script  that 
contains  the  hand  calculation  analysis. 

The  second  form  of  analysis  makes  use  of  the  Thermal  Desktop  modeling  software.  Given  a  3D 
Computer  Aided  Design  (CAD)  model,  this  software  has  the  capability  of  simulating  various 
orbiting  conditions.  Nodes  and  heat  loads  can  be  added  to  the  CAD  model  as  needed  in  order  to 
capture  the  full  behavior  of  the  system.  The  current  thermal  model  has  460  nodes.  Using  the 
Thermal  Desktop  software,  simulations  have  been  run  at  various  orbits  and  sun  incidence  angles. 
It  has  been  used  to  model  the  hottest  and  coldest  cases.  The  cases  include  polar  orbits  where  the 
satellite  is  exposed  to  the  sun  for  the  entire  duration  of  the  orbit  as  well  as  equatorial  orbits. 

The  last  aspect  to  the  thermal  modeling  approach  involves  thermal  vacuum  testing  conducted  at 
MIT  Lincoln  Laboratory.  The  main  purpose  of  the  thermal  vacuum  test  is  to  observe  the  thermal 
behavior  of  the  satellite  and  then  compare  those  findings  with  the  results  from  the  calculations 
and  the  simulations  from  the  previous  analyses.  The  entire  satellite  structure  and  its 
subcomponents  are  put  into  the  vacuum  chamber  and  the  pressure  is  brought  down  to  10  9  torr.  In 
order  to  simulate  heat  loads  from  components,  23  resistors  are  mounted  on  the  satellite.  The 
chamber  temperature  is  then  fluctuated  from  -20  degrees  Celsius  to  20  degrees  Celsius  and  the 
LabView  software  is  used  to  collect  data.  The  output  data  then  gets  correlated  to  the  results  from 
our  first  two  methods  of  analysis.  It  is  used  to  assess  the  validity  of  our  models. 


2.10.4  ENGINE  MOUNT  DESIGN  (A.  ESPITIA  &  W.  PINO) 

The  structures  team  has  completed  their  redesign  of  the  structural  model.  One  of  the  questions 
that  the  design  had  brought  out  was  the  effect  of  reducing  the  size  of  the  radiation  plate.  This 
reduction  would  result  in  heat  to  be  dissipated  from  the  engine  more  slowly  than  before.  The 
concern  the  thermal  team  had  was  whether  this  reduction  would  result  in  more  heat  to  be 
transferred  down  the  engine  mount  posts  to  nearby  electronic  equipment  and  potential  cause 
them  to  reach  high  temperatures.  In  order  to  determine  if  this  design  would  present  a  thermal 
problem,  the  new  design  was  subjected  to  orbital  simulation.  The  results  of  an  orbital  simulation 
of  10  orbits  around  the  equator  at  550  km  above  the  earth’s  surface  with  no  thermal  control  can 
be  seen  in  Figure  2.10-2.  The  different  lines  represent  different  nodes  along  the  four  engine  posts. 
Note:  The  posts  corresponding  to  the  nodes  can  be  seen  in  Figure  2.10-1.  The  nodes  that  are  in 
T20’s  correspond  to  Post  1.  Similarly,  the  T40’s  are  for  post  2,  T50’s  are  for  post  3,  and  the 
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T60’s  are  for  post  4.  Due  to  graphing  limitations  on  Thermal  Desktop,  only  14  nodes  can  be 
plotted  at  once. 


FIGURE  2.10-1:  ENGINE  MOUNT  DESIGN 
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FIGURE  2.10-2:  TEMPERATURE  (K)  VS.  TIME(S)  FOR  ENGINE  POSTS 


The  results  above  show  that  the  engine  posts  tend  to  level  off  at  a  temperatures  of  390K,  which 
could  result  in  a  significant  amount  of  heat  being  transferred  to  key  electronic  equipment  that  is 
mounted  on  the  tank  clamps  (such  as  the  battery  box,  avionics  stack,  and  a  reaction  wheel). 

In  order  to  address  this  problem,  the  thermal  team  applied  Z-93  white  paint  on  the  bottom  of  the 
engine  mount  and  the  four  posts  supporting  the  mount.  The  simulation  was  run  once  again  and 
the  results  can  be  seen  in  Figure  2.10-3. 
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FIGURE  2.10-3:  TEMPERATURE  (K)  VS.  TIME(S)  FOR  ENGINE  POSTS  WITH  Z93 


The  results  show  a  significant  improvement.  The  engine  posts  all  level  off  between  330K  and 
340K.  Additionally,  the  nearby  electronic  equipment  did  not  show  any  significant  increases  in 
their  temperatures  (as  compared  to  the  previous  engine  mount  design  with  a  larger  size).  The 
above  results  show  that  the  new  engine  mount  design  should  not  create  any  significant  thermal 
issues  that  cannot  be  resolved  with  the  use  of  thermal  control. 


2T0.5  INTEGRATED  MODELING  (A.  ESPITIA  &  W.  PINO) 

The  thermal  modeling  requirement  set  in  place  by  the  UNP  program  was  to  have  a  100  node 
SINDA  model  of  the  satellite.  In  order  to  achieve  this  requirement  the  Thermal  Team  has  begun 
by  modeling  individual  components  (battery  box,  anode,  avionics,  composites).  The  individual 
components  are  aggregated  to  the  assembly  level  and  reanalyzed  to  ensure  the  interfaces  between 
components  accurately  represent  the  truth.  Finally  the  assemblies  are  being  combined  into  an 
integrated  CASTOR  thermal  model.  Components  requiring  >1W  continuous  will  be  included  in 
the  integrated  thermal  model.  All  components  operating  at  less  than  1W  are  assumed  to  approach 
the  temperature  of  their  adjacently  mounted  component.  Though  unspecified,  components  that 
require  <10  W  sporadically  (such  as  the  DCFT)  will  also  be  modeled.  The  CASTOR  SINDA 
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model  currently  has  over  400  nodes  dispersed  between  20  different  components.  Analysis  of  the 
assembly  and  integrated  models  has  been  made  and  is  still  ongoing  as  component  and  the 
structural  layout  change. 

The  comments  and  suggestions  gathered  at  the  preliminary  design  review  led  to  a  structural 
redesign  of  CASTOR,  which  was  completed  at  the  beginning  of  2010.  As  a  result,  the  thermal 
team  also  adjusted  its  thermal  model  in  order  to  best  resemble  the  new  design.  The  new  thermal 
model  can  be  seen  inFigure  2.10-4.  Aside  from  the  solar  array  configuration  change,  two  new 
boxes  (which  will  house  a  majority  of  the  electronic  components)  were  placed  on  the  tank 
clamps  on  either  side  of  the  satellite  (only  one  is  visible  in  the  figure  below).  Though  this  model 
is  simply  the  previous  model  adjusted  for  the  redesign,  the  thermal  team  has  planned  another 
TVac  test  to  once  again  validate  its  model  as  well  as  apply  some  thermal  control. 


FIGURE  2.10-4:  INTEGRATED  THERMAL  DESKTOP  MODEL 


Using  the  updated  thermal  model  (which  has  been  validated  at  an  earlier  design),  the  team  has 
run  simulation  in  order  to  determine  the  areas  in  need  of  thermal  control.  A  simulation  of  10 
orbits  (so  that  it  would  reach  steady  state)  at  550  km  (see  Figure  2.10-5)  was  run.  The  results  are  in 
Figure  2.10-6. 
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FIGURE  2.10-5:  SIMULATION  ORBIT 
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FIGURE  2.10-6:  SIMULATION  RESULTS 

The  results  show  that  the  majority  of  the  satellite  tends  to  heat  up  too  quickly.  To  address  this, 
the  team  decided  on  using  a  highly  emissive  paint,  Z93  white  paint  (s  =  0.92).  Since  solar  cells 
operate  better  in  the  cold  than  in  the  heat,  the  back  of  all  4  solar  arrays  and  the  engine  (mount 
included)  were  covered  in  Z93.  Also,  a  mounting  plate  was  placed  behind  the  two  main 
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electronic  boxes  to  provide  additional  structural  integrity  as  well  as  a  conduction  path  so  heat  can 
be  dissipated  away  from  them.  After  adjusting  the  thermal  model  for  the  proposed  thermal 
control,  the  same  simulation  was  run.  The  results  are  shown  in  Figure  2.10-7. 
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FIGURE  2.10-7:  SIMULATION  RESULTS  WITH  THERMAL  CONTROL 


With  thermal  control,  the  results  that  were  yielded  were  significantly  better.  Only  the  engine 
exceeded  50°C  and  only  the  solar  panels  fell  below  0°C.  This  simulation  however,  was  only  for 
an  equatorial  orbit.  In  order  to  have  range  of  possible  temperature  components  could  see  due  to 
various  orbits,  additional  simulation  were  run.  The  altitude,  inclination,  and  beta  angle  were  all 
adjusted.  A  graphic  representation  of  the  hottest  and  coldest  cases  for  the  components  can  be 
seen  in  Figure  2.10-8  where  the  bars  represent  the  predicted  temperature  ranges  while  the  lines 
represent  the  operating  temperature  ranges. 
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FIGURE  2.10-8:  PREDICTED  AND  OPERATING  TEMPERATURE  RANGES 

Some  components  have  the  same  cold/hot  temperature  since  they  are  located  in  the  same  place 
(i.e.  inside  one  of  the  boxes).  Additionally,  some  margins  are  large  due  to  the  large  operating 
temperature  ranges  of  some  of  the  components.  The  model  indicates  that  the  requirement  of 
giving  the  satellite  adequate  control  will  be  met. 


2.10.6  THERMAL  TESTING  (A.  ESPITIA) 

The  thermal  team  aims  to  validate  models  created  in  Thermal  Desktop  with  hand  calculations  in 
MATLAB  and  test  data  collected  from  a  variety  of  test.  In  order  to  create  fidelity  in  the  models 
created  in  Thermal  Desktop,  preliminary  modeling  of  a  structural  fin  was  done  in  both  Thermal 
Desktop  and  MS  Excel,  and  then  tested  in  the  clean  room.  The  model  predicts  the  temperatures 
at  the  various  sensor  locations  to  within  3  degrees  Kelvin.  The  stated  tolerance  on  the 
specification  sheets  is  3  degrees  at  the  temperature  range  that  the  sensors  were  operating  within. 
The  first  round  of  analysis  indicated  that  the  model  was  significantly  off  of  the  actual  test  data. 
Figure  2.10-9  through  Figure  2.10-13show  the  fin  sensor  layout  (denoted  by  the  black  circles)  and 
resistive  heater  (in  yellow),  test  setup  pictures,  thermal  desktop  meshed  model,  the  transient 
response  of  the  test,  the  thermal  desktop  model  results,  and  finally  the  actual  test  data  results. 
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FIGURE  2.10-9:  THERMAL  FIN  SENSOR  LAYOUT 


FIGURE  2.10-10:  THERMAL  DESKTOP  FIN  MODEL 
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FIGURE  2.10-11:  THERMAL  DESKTOP  TRANSIENT  TEST  RUN 


FIGURE  2.10-12:  THERMAL  DESKTOP  FIN  MODEL  DATA 


16.83  CASTOR  Design  Document 


Page  247 


November  18,  2010 


Sensor  Data 


Time  (sec) 


FIGURE  2.10-13:  THERMAL  FIN  SENSOR  DATA 


The  spikes  in  the  resistor  sensor  were  due  to  accidental  changes  in  the  current  going  to  the 
sensors  in  combination  with  the  error  in  the  output  of  the  sensor.  The  following  are  the  input 
conditions  given  to  Thermal  Desktop  in  order  to  properly  model  the  test  environment. 

■  Conduction,  convection,  radiation,  heat  input 

■  Same  conditions  as  the  steady  state 

■  Resistor  initial  temp  @  293. 15K 

■  Aluminum  plate  initial  temp  @  293. 15K 

■  Ambient  environment  @  293. 15K 

■  Test  case  run  for  3600  sec  (1  hour)  at  100  sec  intervals  (5000  rays  per  surface) 

■  Final  temp  mimics  steady  state  as  expected 

■  Initial  temp  for  all  objects  is  as  stated 

■  Model  predicts  a  faster  rise  in  temperature  than  the  sensors  display 

■  Model  final  temperatures  are  accurate  to  within  3  degrees  of  data 

■  Sensors  are  rated  to  +/-  3  degree  accuracy 
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Clearly  there  is  a  significant  discrepancy  between  the  actual  and  model  data.  While  the  steady 
state  temperatures  only  vary  by  a  few  degrees  the  time  constant  of  the  model  is  much  higher  than 
that  of  the  actual  data.  This  led  to  a  resulting  investigation  of  the  sensors  themselves.  It  is 
believed  that  the  sensors  naturally  see  a  time  lag  in  the  temperatures  that  they  record  due  to  the 
resistance  of  the  plastic  material.  Adding  in  the  sensors  to  the  Thermal  Desktop  model  resulted  in 
far  closer  model/data  correlation.  Additionally,  accurately  modeling  the  ambient  temperature 
brought  the  steady  state  temperatures  even  closer  than  in  Test  1. Figure  2.10-14  through  Figure 
2.10-16show  the  data  for  the  ambient  environment  that  was  added  to  the  Thermal  Desktop  fin 
model,  the  4  sensor  additions  to  the  mesh  layout,  and  finally  the  resulting  model/data  correlation. 

Potential  Error  Sources: 

■  Sensor  time  lag 

■  Resistance  of  the  sensor  not  taken  into  account 

■  Material  properties  were  not  exact 

■  Ambient  temperature  was  a  constant 

■  Glue  did  not  hold  sensors  on  aluminum  well 

■  Thermal  resistance  of  the  glue  not  considered 

■  Radiating  to  black  body  instead  of  room  temp 


Ambient  Environment 


FIGURE  2.10-14:  AMBIENT  ENVIRONMENTAL  DATA 
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■  Added  4  sensors  to  the  model 

■  Black  Plastic  radiates  with  solar  absorptivity  0.96  and  IR  emissivity  0.85  (a/s  = 
1.129) 

■  Sampled  model  at  sensor  nodes 

■  Resistance  of  plastic  resistors  should  affect  the  time  constant  of  the  temperature 
response 

■  Changed  aluminum  material  property  to  A1  7079  (K=121.34) 

■  Heavily  oxidized  aluminum  has  solar  absorptivity  0.96  and  IR  emissivity  0.85 
(a/s  =1.129) 

■  Matched  ambient  temperature  profile,  which  shows  our  model  is  consistent  with  the  test 
data. 


FIGURE  2.10-15:  THERMAL  DESKTOP  MODEL  CHANGES 
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Figure  2.10-16:  Test  2  Model/Data  Correlation 
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2.10.7  SOLAR  ARRAY  COMPOSITE  TESTING  (A.  ESPITIA) 

2.10.7.1  PURPOSE 

The  structures  team  has  assembled  three  potential  layouts  that  will  be  thermally  and  structurally 
tested  and  analyzed  to  determine  the  best  (most  mass  efficient,  best  thermal  characteristics  to 
keep  cell  temperatures  in  the  right  range,  and  meeting  the  ESPA  and  UNP  launch  load  structural 
requirements. The  purpose  of  the  solar  array  composite  testing  was  to  determine  which  composite 
performed  ‘best’  from  a  thermal  perspective.  ‘Best’  performance  can  be  defined  as  keeping  the 
critical  components  within  their  optimal  range  while  maximizing  their  lifetime.  Solar  cells  prefer 
to  operate  at  —25C.  The  three  design  possibilities  are  identified  and  shown  below. 

•  Design  1 :  Carbon  fiber/ Aluminum  honeycomb  composite,  Fr4  PCB  board,  cells 

•  Design  2:  Aluminum  sheet/Aluminum  honeycomb  composite,  Fr4  PCB  board,  cells 

•  Design  3:  Aluminum  2D  isogrid,  Fr4  PCB  board,  cells 


Thermal  Diagram  -  Carbon  Composite 
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FIGURE  2.10-17:  CARBON  COMPOSITE  FAYOUT 
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Thermal  Diagram  -  Aluminum 
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FIGURE  2.10-18:  ALUMINUM  LAYOUT 


Thermal  Diagram  -  Isogrid 
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FIGURE  2.10-19:  ALUMINUM  ISOGRID 

2.10.7.2  TEST  PLAN 

A  Thermal  desktop  model  of  three  different  composite  layouts  was  developed  and  analyzed.  The 
three  options  included  the  carbon  honeycomb  composite  layout,  the  aluminum  phase  sheet  and 
honeycomb  layout,  and  the  solid  aluminum  sheet.  Each  of  the  three  designs  was  also  tested  with 
the  addition  of  the  PCB  board  and  four  solar  cells.  The  thermal  desktop  models  were  compared 
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to  temperature  data  collected  at  room  temperature.  The  test  setup  can  be  seen  in  Figure  2.10-20 
and  Figure  2.10-21. 


FIGURE  2.10-20:  THERMAL  FIN  TEST  SETUP  1 


FIGURE  2.10-21:  THERMAL  FIN  TEST  SETUP  2 
2.10.7.3  RESULTS 
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After  analyzing  the  results,  the  aluminum  sheet  performed  best  with  the  aluminum  phase  sheet 
and  honeycomb  at  a  close  second.  According  to  the  composite  MATLAB  models  we  can  expect 
to  see  temperatures  in  the  range  of  -46  to  25  degrees  Celsius  using  the  aluminum  phase  sheet  and 
honeycomb  design.  While  this  design  is  nearly  twice  as  heavy  as  the  carbon  composite  and 
honeycomb  design,  it  will  keep  the  solar  cells  within  the  desired  temperature  range  allowing 
them  operate  at  their  maximum  efficiency  point. 

2.10.7.4  CONCLUSION 

The  Thermal  Team’s  conclusion  is  that  the  aluminum  sheet  with  honeycomb  design  will  give  the 
best  thermal  performance  at  the  lowest  mass  cost.However,  the  structures  team  has  decided  to 
use  an  aluminum  honeycomb  composite  with  PCB  on  both  sides,  which  benefit  the  power  team’s 
wiring  of  solar  cells  and  found  to  the  best  panel  design  during  vibration  test.  Though  it  is  not  the 
best  thermal  design  in  terms  of  conduction,  the  proposed  design  was  still  shown  to  perform  well 
thermally  and  keep  the  solar  cells  near  their  optimal  operating  range  of  -25  °C. 


2.10.8  AVIONICS  FLATSAT  TESTING  (A.  ESPITIA) 

2.10.8.1  PURPOSE 

In  order  to  monitor  the  temperature  of  various  components  of  the  satellite,  the  thermal  subsystem 
will  use  20  sensors  to  do  so.  The  figure  below  outlines  the  sensor  locations.  Fourteen  (in  red)  are 
LM19  analog  sensors  (see  page  276)  that  will  be  able  to  connect  and  obtain  power  from  one  of 
the  PICs  in  the  avionics  system.  The  six  (in  yellow)others  are  K-type  thermocouples,  which  are 
more  robust  and  have  a  larger  range  of  temperatures  it  can  monitor.  The  thermocouple  will  also 
interface  with  the  avionics  system  through  a  PIC. 
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FIGURE  2.10-22:  SENSOR  LOCATION  DIAGRAM 

The  purpose  of  the  Avionics  Flatsat  testing  is  to  show  that  the  Avionics  system,  in  particular  the 
Pic,  can  read,  store,  and  transmit  data  from  the  thermal  sensors  that  are  to  be  used  to  monitor  the 
temperatures  of  components  of  the  satellite  throughout  its  mission  lifetime. 

2.10.8.2  TEST  PLAN 

The  LM19  sensors  and  the  K  type  thermocouples  will  be  connected  to  one  of  the  PICs  on  the 
Avionics  system,  where  they  can  transmit  data  and  receive  power  and  ground  (if  necessary). 
Once  properly  connected,  the  code  that  runs  the  Avionics  system  will  begin  to  run  and  start 
reading  the  data.  It  will  continue  to  read  the  sensor  data  throughout  the  duration  of  the  test, 
which  will  be  TBD  minutes.  The  PIC  will  store  and  transmit  the  data  as  commanded/necessary. 

2.10.8.3  SCHEDULE 

The  Avionics  Flatsat  testing  will  be  broken  down  into  three  main  phases.  The  first  is  to  show  that 
the  PIC  is  able  to  read  one  of  thermal  sensors.  That  part  has  been  partially  completed  since  the 
PIC  was  able  to  read  one  of  the  LM19  analog  sensors.  The  team  still  must  test  its  ability  to  read  a 
thermocouple.  That  is  scheduled  to  be  done  in  June  2010  once  the  proper  thermocouple 
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interfaces  are  designed.  The  second  main  phase  is  the  ability  to  store  the  sensor  data  in  proper 
files  in  the  allocated  memory.  This  is  tentatively  scheduled  to  take  place  in  late  June  2010.  The 
third  phase  of  the  testing  is  the  ability  to  transmit  the  stored  data  back  to  the  ground,  where  the 
data  can  be  processed/used  as  necessary.  The  test  date  for  this  is  tentatively  also  scheduled  in  late 
June  2010. 


2.10.9  LAB  WORK:  ENGINE  TESTING  (A.  ESPITIA  &  W.  PINO) 

2.10.9.1  PURPOSE 

The  purpose  of  the  Engine  Testing  is  to  monitor  the  temperatures  the  engine  experiences  during 
operation,  ensure  that  they  are  below  327°C,  the  critical  temperature  of  the  engine,  and  to  record 
this  data  and  incorporate  it  into  current  thermal  models  of  the  engine.  Additionally,  the  test 
results  will  aid  in  the  thermal  design  over  the  engine,  the  mount  it’s  placed  on,  and  the  four  posts 
that  connect  the  mount  to  the  top  tank  clamp.  Currently,  the  thermal  design  has  Z93  paint  on  all 
components  in  order  to  keep  the  temperature  the  components  will  experience  at  low  temperatures 
(less  than  450K). 


2.10.9.2  TEST  PLAN 

A  thermal  model  based  on  known  values  of  the  engine  was  developed  in  Thermal  Desktop  and 
MATLAB  (see  Section  5.9.2)  and  evaluated.  The  engine  will  be  placed  in  a  vacuum  chamber  at 
room  temperature,  22°C,  and  turned  on.  As  it  will  be  on  the  satellite,  a  Type  K  Thermocouple 
will  be  placed  at  the  base  of  the  anode  and  at  the  base  of  the  outer  shell  of  the  engine.  The 
temperature  readings  will  be  monitored  and  recorded  until  the  engine  has  reached  a  steady  state. 
The  actual  temperature  readings  measured  will  be  compared  to  the  results  from  hand  calculations 
and  Thermal  Desktop.  The  thermal  models  will  then  be  adjusted  as  needed. 


2.10.9.3  SCHEDULE 

The  Engine  test  is  currently  ongoing  in  the  Space  Propulsion  laboratory  in  coordination  with  the 
Propulsion  team.  Four  K-type  thermocouples  (provided  by  Aurora  Flight  Sciences)  will  be 
placed  in  various  locations  on  the  engine.  The  engine  first  must  be  conditioned  for  four  hours 
prior  to  firing. 


2.10.9.4  SKILLS  ACQUIRED 

Similar  to  the  solar  array  composite  testing  (described  earlier)  and  the  TVac  test,  the  thermal 
team  has  and  is  still  developing  important  skills.  The  main  skill  the  team  has  learned  from  lab 
work  is  validating  Thermal  Desktop  models  by  correlating  prediction  the  model  makes  with 
actual  test  data.  The  team  has  learned  how  to  properly  carry  out  a  test  from  start  (writing  the  test 
plan)  to  end  (analyzing  the  data).  Additionally,  the  team  gained  the  skills  of  modeling  test 
environments  in  Thermal  Desktop,  such  as  creating  a  vacuum  chamber  to  place  the  engine  in 
order  to  accurately  model  the  actual  test  setup.  This  also  included  specifying  the  proper  input 
variables  (ambient  temperature,  conductivity,  convection  coefficient,  any  boundary  conditions). 
This  will  allow  the  team  to  have  model  prediction  in  conjunction  with  test  data  so  the  two  sets 
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data  can  be  correlated  and  the  Thermal  Desktop  models  can  be  validated.  After  validation,  the 
team  is  able  to  revise/make  a  final  design  choice  in  the  thermal  design  of  the 
components/satellite. 
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3  BEYOND  PQR 


3.1  FCR  (L.  JOHNSON) 

FCR  will  be  held  in  Albuquerque,  NM  on  January  17th,  2011.  Due  at  FCR  are  a  set  of 
documents  that  full  describe  and  analyze  the  satellite  design.  These  documents  are  due  to  UNP 
by  December  27th,  2010.  At  FCR  the  Satellite  Team  will  have  15  minutes  to  present  on  the 
design  and  20  minutes  to  demonstrate  the  satellites  functionality  at  a  booth.  The  winning 
satellite  will  be  chosen  at  the  end  of  the  day.  If  CASTOR  is  chosen,  we  will  enter  Phase  2  of  the 
University  Nanosat  Program  and  will  need  to  deliver  a  completed  satellite  to  AFRL  by  June  for 
complete  environmental  and  functionality  testing.  The  required  documents  are  listed  on  the 
fileshare. 

[The  Deliverables  List  will  found  in  Section  42.78  of  the  Fileshare  as 
Deliverable_Status.xlsx] 


3.2  ASSEMBLY  PLANS  (L.  JOHNSON) 

The  purpose  of  this  document  is  to  describe  the  specifications  and  methods  by  which  parts  of  the 
spacecraft  will  be  reassembled  when  dismantled  for  testing. 

Each  subteam  is  responsible  for  the  development  of  assembly  plans  for  their  subsystem. 
Structures  and  Systems  team  are  responsible  for  the  system  wide  assembly  plan.  These  plans 
will  be  used  once  the  satellite  has  been  handed  over  to  ALRL  for  testing  and  launch. 

[The  Assembly  Plans  will  found  in  Section  4.2.7. 1  of  the  Fileshare  in  the 

Assembly  Plan  Documentation  folder] 

3.3  VEHICLE  INTEGRATION  PLAN  (A.  FUHRMANN) 

The  purpose  of  this  document  is  to  describe  the  plan  and  methods  that  will  be  used  for 
integrating  the  various  subsystems  into  a  cohesive  vehicle.  It  provides  the  overarching 
procedures  and  schedule  to  be  used.  Supplemental  documentation,  primarily  the  ICDs  and 
mechanical  drawings,  further  defines  how  the  integration  must  be  performed. 

For  each  subsystem,  it  will  first  be  tested  per  the  integration  plan  functionality  tests  by  the  “ready 
for  integration”  date.  Then  it  will  be  integrated  per  the  procedure  described  with  the  help  of  the 
relevant  ICDs  by  those  listed  under  tasking  by  the  “integrated”  date.  To  this  end,  the  relevant 
mechanical  ICD  can  be  used  to  find  the  appropriate  mounting  information  (such  as  bolt  hole 
pattern).  Further  physical  envelopes  of  the  different  parts  are  provided  in  the  mechanical 
drawings.  The  data  and  power  ICDs  can  be  used  to  find  the  specifications  and  connections  to  the 
data  and  power  connections.  Finally,  the  system  will  be  wired  with  both  data  and  power  per  the 
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ICDs  and  tested  again  for  functionality  by  the  “wired”  date.  See  the  Integration  Plan  section  of 
the  Design  Document  for  full  details  on  the  general  procedures  and  standards. 

[The  Integration  Plan  may  be  found  in  Section  2.7  of  the  Filesliare  as 

CASTOR-Manufacturing_Plan.doc] 

3.4  TESTING  PLAN  (K.  ANDERSON) 


All  test  plans  can  be  found  in  the  associated  test  plans.  The  three  system  level  tests  are  the 
Balloon  SHOT  (II),  Vibration,  and  Thermal  Vacuum  test  and  are  listed  with  the  subsystem 
performing  them. 

Index  of  tests  (all  plans  and  results  are  available  in  Appendix  5.6. 

•  Avionics 

o  EMC/EMI  (August  2010) 

o  FlatSat  I  (Ground  station  Communications)  (November  2009) 
o  FlatSat  II  (Read  Thermal/Power  Sensor  Data)  (May  2010) 
o  FlatSat  III  (Read/Operate  ACS  sensors)  (May  2010) 
o  FlatSat  IV  (PPU/Linear  Actuators/Inhibits)  (May  2010) 
o  FlatSat  V  (Operate  XFS)  (May  2010) 
o  FlatSat  VI  (Radiation  effects)  (May  2010) 
o  Balloon  SHOT  (II)  (June  ll-13th  2010) 

•  Communications 

o  Antenna  (April  2010) 

•  ACS 

o  GPS  (November  2009) 
o  Magnetometers  (March  2010) 
o  Reaction  Wheels  (March  2010) 
o  Torque  Coils  (June  2010) 
o  Sun  Sensors  (October  2010) 

•  Power 

o  Integrated  PPU  (May  2010) 
o  MPPT  (July  2010) 
o  On-board  Charger  (May  2010) 
o  PDU  (April  2010) 
o  FlatSat  (August  2009) 
o  Solar  Power  (April  2010) 
o  PDU  converter  (Summer  2010) 

•  Structures 

o  Vibration  (March  2009,  February  2010,  October  2010) 
o  Thermal- Vacuum  (March  2010,  October  2010) 

•  Science 

o  Camera  Avionics  (May  2010) 
o  Camera  Functional  (September  2010) 
o  Camera  Thermal- Vacuum  (April  010) 
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o  Camera  Vibration  (April  2010) 
•  Propulsion 

o  DCFT  Efficiency  (April  2010) 
o  Feed  System  (June  2010) 
o  Integrated  PPU  (May  2010) 
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5  APPENDICES 


5.1  REQUIREMENTS  (K.  ANDERSON) 


[The  RVM  may  be  found  in  Section  2.6  of  the  Fileshare  as  CASTOR-RVM-clean ] 


5.2  MASTER  EQUIPMENT  LIST  (G.  FRITZ) 


[The  MEL  may  be  found  in  Section  2.1.2  of  the  Fileshare  as  UNP  -MEL-Current] 

5.3  INTERFACE  CONTROL  DOCUMENTS  (A.  FUHRMANN) 


[The  ICDs  may  be  found  in  Section  2.2-Interfaces  Management  of  the  Fileshare .] 


5.4  SCHEDULE  (G.  FRITZ) 


[The  Schedule  may  be  found  in  Section  1.1  of  the  Fileshare  as  Full  Schedule] 


5.5  RISK  MATRIX  (J.  JAMES) 


[The  risk  matrix  may  be  found  in  Section  2.5  of  the  Fileshare  as  Risk_Mitigation] 

5.6  TESTING  PLANS  (K.  ANDERSON) 


[The  testing  plans  may  be  found  in  Section  2.4.1  of  the  Fileshare  as  Testing_Plans] 


5.7  CAD  DRAWINGS  (E.  PETERS) 


[Larger  versions  of  the  CAD  Drawings  may  be  found  in  Section  5.3.12.3  of  the  Fileshare  as 
*-pdf 7 
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Figure  4.9  -  1:  Avionics  box  assembly 
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Figure  4.9  -  2:  Battery  box  assembly 


Figure  4.9  -  3:  Bottom  antenna  assembly 
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Figure  4. 9  -  4:  Brackets  and  braces  assembly 
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NOTES: 

A  PROFILE  DIMENSIONS  ARE  REFERENCE  ONLY 
CUT  FILE  SERVES  AS  PROFILE  MASTER 


A 


UNLESS  OTHERWISE  SPECIFIED, 
PROFILE  TOLERANCES  ARE  SHEET 
DEFAULT  DIMENSIONS  AND 
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Figure  4.9  -  5:  CASTOR  Deployed  Configuration 
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NOTES: 


A  PROFILE  DIMENSIONS  ARE  REFERENCE  ONLY 
CUT  FILE  SERVES  AS  PROFILE  MASTER 


A  UNLESS  OTHERWISE  SPECIFIED. 

PROFILE  TOLERANCES  ARE  SHEET 
DEFAULT  DIMENSIONS  AND 


ITEM  NO. 

DESCRIPTION 

QTY. 

' 

Magnet  Bracket  Bottom 

1 

2 

Magnet 

1 

3 

Magnet  Bracket  Top 

1 

Figure  4. 9-  6:  Magnet  bracket  assembly 
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Figure  4.9  -  7:  Solar  pane 1 1 
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NOTES: 


A  PROFILE  DIMENSIONS  ARE  REFERENCE  ONLY 
CUT  FILE  SERVES  AS  PROFILE  MASTER 


A  UNLESS  OTHERWISE  SPECIFIED, 

PROFILE  TOLERANCES  ARE  SHEET 
DEFAULT  DIMENSIONS  AND 


3  2 


ITEM  NO. 

DESCRIPTION 

QTY 

1 

1321-01  Solar  Panel  2  Honeycomb 

1 

2 

1321-02  Solar  Panel  2  FR4 

2 

3 

Solar  Panel  Cells 

8 

Figure  4.9  -  8:  Solar  panel  2 


A 
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PROFILE  DIMENSIONS  ARE  REFERENCE  ONLY 
CUT  FILE  SERVES  AS  PROFILE  MASTER 

UNLESS  OTHERWISE  SPECIFIED, 

PROFILE  TOLERANCES  ARE  SHEET 
DEFAULT  DIMENSIONS  AND 


ITEM  NO. 

DESCRIPTION 

QTY 

1 

Solar  Panel  Cells 

8 

2 

1331-01  Solar  Panel  3  Honeycomb 

1 

3 

1331-02  Solar  Panel  3  FR4 

2 

A 

A 


SiZE  DWG.  NO. 

B 

SCA.E:  NONE  WEIGHT: 


01 
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Figure  4.9  -  9:  Solar  panel  3 
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Figure  4.9  -  10:  Solar  panel  4 


A 

A 


UNLESS  OTHERWISE  SPECIFIED. 
PROFILE  TOLERANCES  ARE  SHEET 
DEFAULT  DIMENSIONS  AND 


ITEM  NO. 

DESCRIPTION 

QTY. 

1 

Solar  Panel  Deployment  Track 

1 

2 

Solar  Panel  Deployment  Block 

1 
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Solar  Panel  Deployment  Pivot  1 

1 

4 

Solar  Panel  Deployment  Arm 

1 

5 

Solar  Panel  Deployment  Pivot  2 

Solar  Panel  Deployment  Assembly 
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B 

SCA.S:  NONE  WEIGHT: 
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Figure  4.9  -  12:  Solar  Panel  Deployment  Mechanism  assembly 
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A 


TORQUE  PER  MSFC-STD-4868 


ITEM  NO. 

DESCRIPTION 

Default  Exploded 

View/QTY. 

1 

1 110-01  Xenon  Tank 

1 

2 

1 1 1 0-02  Tank  Clamp  Bottom 

1 

3 

1 1 10-04  Tank  Clamp  Top 

1 

4 

1 1 1 0-03  Tank  Clamp  Middle 

1 

5 

Battery  Box  Assembly 

1 

6 

Avionics  Box  Assembly 

1 

7 

Reaction  Wheel 

1 

S 

Bottom  Antenna 

1 

9 

Bottom  Antenna  Upper  Bracket 

1 

10 
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11 

Thruster  Assembly 
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Figure  4.9  - 13:  Tank  section 
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UNLESS  OTHERWISE  SPECIFIED. 
PROFILE  TOLERANCES  ARE  SHEET 
DEFAULT  DIMENSIONS  AND 


ITEM  NO. 

PART  NUMBER 

Default  Exploded 

View/QTY. 

1 

1 141-11  Thruster  Mounting  Plate  Stilt 

4 

2 

1 142-12  Anode 

1 

3 

1 141-10  Thruster  Mounting  Plate  (TMP) 

1 

4 

1 142-13  Cathode 

1 

5 

Thermal  Isolation  Washers 

4 
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Figure  4.9  -  14:  Thruster  assembly 
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A 

A 


UNLESS  OTHERWISE  SPECIFIED, 
PROFILE  TOLERANCES  ARE  SHEET 
DEFAULT  DIMENSIONS  AND 


ITEM  NO. 

DESCRIPTION 

QTY. 

1 

1211-01  Truss  1 

1 

2 

1 006-00  Solar  Panel  Release 
Mechanism  Assembly 

2 

3 

Camera  Enclosure 

1 
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Figure  4.9  -  15:  Truss  1 
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NOTES: 

A  PROFILE  DIMENSIONS  ARE  REFERENCE  ONLY 
CUT  FILE  SERVES  AS  PROFILE  MASTER 

A  UNLESS  OTHERWISE  SPECIFIED, 

PROFILE  TOLERANCES  ARE  SHEET 
DEFAULT  DIMENSIONS  AND 


ITEM  NO. 

DESCRIPTION 

QTY. 

1 

1221-01  Truss  2 

1 

Figure  4.9  -  16:  Truss  2 
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A 
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UNLESS  OTHERWISE  SPECIFIED. 
PROFILE  TOLERANCES  ARE  SHEET 


ITEM  NO. 

DESCRIPTION 

QTY. 

1 

1231-01  Truss  3 

1 

2 

Pressure  Relief  Valve 
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3 

Manual  Relief  Valve 

1 

4 

Manual  Relief  Valve  Bracket 

' 

5 

Pressure  Relief  Valve  Bracket 
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Figure  4.9-1 7:  Truss  3 
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NOTES: 

A  PROFILE  DIMENSIONS  ARE  REFERENCE  ONLY 
CUT  FILE  SERVES  AS  PROFILE  MASTER 

A  UNLESS  OTHERWISE  SPECIFIED. 

PROFILE  TOLERANCES  ARE  SHEET 
DEFAULT  DIMENSIONS  AND 


ITEM  NO. 

DESCRIPTION 

QTY. 

1 

1 241-01  Truss  4 

1 
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Figure  4.9  -  18:  Truss  4 
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ITEM  NO. 

DESCRIPTION 

QTY. 

1 

Truss  Mounted  Antenna  Bracket 

1 

2 

Truss  Mounted  Antenna 

A 


UNLESS  OTHERWISE  SPECIFIED. 
PROFILE  TOLERANCES  ARE  SHEET 
DEFAULT  DIMENSIONS  AND 


A 
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Truss  Mounted  Antenna  Assembly 
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01 
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Figure  5.7  -  19:  Truss-mounted  antenna  assembly 


5.8  ALTERNATIVE  SCIENCE  MISSIONS  (L.  TAMPKINS) 


5.8.1  CASTOR  ALTERNATIVE  SCIENCE  GOALS 


The  main  mission  of  the  CASTOR  Science  and  Payload  Team  is  to  design  and  engineer 
devices  that  are  properly  integrated  with  the  satellite’s  system  whose  main  function  is  to  collect 
scientific  data  during  the  CASTOR  mission.  Possible  missions  that  would  collect  science  worthy 
data  and  measurements  will  be  outlined  here.  The  possible  missions  are  divided  into  three 
categories  based  on  the  locations  of  observations;  these  categories  are  near-earth,  lunar  (which 
includes  asteroids),  and  exosolar.  The  technique  of  synthesis  imaging  will  be  used  in  missions 
that  involve  radio  or  ultraviolet  astronomy;  hence,  a  brief  outline  of  synthesis  imaging  and  how  it 
applies  to  the  capabilities  of  the  CASTOR  satellite  is  given. 


5.8.2  NEAR  EARTH  MISSIONS 


Earth  radiation  belts:  Understanding  the  extent  and  magnitude  of  various  sections  of  the  belts,  as 
well  as  accurately  forecasting  space  weather,  will  increase  the  safety  of  manned  space  missions 
and  the  efficiency  of  satellites.  Possible  studies  include  investigating  how  the  whistler  mode 
chorus  and  its  interaction  with  charged  particles  within  the  belts.  Examples  include  how  they 
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might  relate  to  magnetic  storms,  sub-storms,  and  aurora  displays.  Another  study  includes 
understanding  very  low  frequency  (VLF)  waves  in  the  belts  to  create  models  to  predict  space 
weather. 

Space  weather  with  a  focus  on  substorms:  Little  data  has  been  collected  on  substorms  because  of 
their  distance  from  Earth  and  their  large  size.  Multiple  passes  by  a  single  satellite  studying  the 
region  has  yet  to  be  recorded.  One  study  could  be  devoting  the  satellite  to  orbits  that 
continuously  cross  the  magnetotail  region  and  perform  various  measurements.  Such 
measurements  could  include  data  collection  on  how  substorms  disrupt  orderly  flow  of  plasma  in 
the  cross-tail  current. 

Cosmic  rays  with  a  focus  on  shock  acceleration: Like  radiation,  cosmic  rays, energetic  particles  in 
space,  are  a  threat  to  manned  spacecraft  and  electrical  components.  Scientists  still  do  not  know 
where  cosmic  rays  originate  from.  This  also  means  that  the  origin  of  the  particles’  energies  is 
unknown.  However,  one  theory  suggests  that  shock  acceleration  may  contribute  particles  energy. 
Unlike  the  particles  origin  shock  acceleration  can  be  observed  in  the  magnetosphere.  A  study 
could  be  done  in  the  magnetosphere  measuring  various  aspects  of  shock  acceleration  and  cosmic 
rays  in  order  to  find  a  correlation. 

Magnetosphere  waves: The  magnetosphere  contains  many  “waves”  that  vary  in  frequency  due  the 
density  of  the  surrounding  plasma  and  magnetic  field.  Such  waves  include  whistlers,  Alfven 
waves,  micropulsations,  hybrid  wave  modes,  auroral  kilometric  radiation  etc. This  is  still  a  pretty 
open  field  of  research  for  many  the  roles  that  these  waves  play  in  space  have  yet  to  be  fully 
understood.  One  study  could  be  inserting  the  satellite  in  the  magnetosphere  with  the  proper 
instruments  to  investigate  the  waves  (one  type  of  wave)  and  how  they  interact  with  their 
surrounding  environment. 


5.8.3  LUNAR  MISSIONS 


Lunar  gravitational  fields: The  Moon  has  a  weak  gravitational  field  that  drastically  varies  in  some 
areas.  The  current  theory  is  that  the  gravitational  anomalies  are  due  to  dense  lava  flows  called 
mascons  that  are  found  in  some  impact  basins.  Since  it  affects  the  orbits  of  spacecraft  travelling 
near  or  around  the  moon  scientists  have  mapped  out  the  gravitational  field  of  the  moon;  however, 
the  exact  cause  of  the  variations  are  still  unknown.  Lurther  study  could  be  done  on  how  various 
surface  features,  such  as  mascons,  contribute  the  lunar  gravitational  field.  Any  data  collection 
and  analyst  would  have  to  go  beyond  simple  mapping  or  measuring  the  field  or  surfaces,  but 
creating  an  active  model  showing  how  specific  sources  contribute  the  overall  field. 

Lunar  outgassing  and  transient  lunar  phenomenon:  Outgassing  is  the  venting  of  elements  and 
molecules  such  as  radon,  nitrogen,  carbon  monoxide,  and  carbon  oxide  from  the  moon’s  surface. 
Scientists  are  not  completely  sure  about  the  origin  of  these  gases;  however,  theories  suggest  that 
they  are  the  result  of  volcanic  or  tectonic  activity  underneath  the  moon’s  surface.  Since  these 
compounds  that  are  emitted  are  the  main  components  of  the  lunar  atmosphere,  understanding 
what  causes  outgassing,  and  where  it  is  most  likely  to  occur  is  important  in  understanding  not 
only  the  activities  below  the  lunar  surface  but  also  the  lunar  atmosphere.  Nitrogen  and  Carbon 
are  important  substances  that  will  be  needed  in  sustained  missions  on  the  moon.  Possible  studies 
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include  radio  scans  that  penetrate  more  than  20  meters  into  the  lunar  surface,  spectroscopy 
measurements  to  study  the  connection  between  lunar  outgassing  and  transient  lunar 
phenomenon,  and  very  low  lunar  orbits  for  in  situ  studies  of  outgassing.  Examples  of 
spectroscopy  measurements  are  be  done  by  alpha  particle  spectrometers,  mass  spectrometers; 
also,  radon  and  muon  emissions  could  be  measured  as  well.  Various  techniques  to  triangulate 
outgassing  sources  are  also  within  the  capabilities  of  CASTOR. 


5.8.4  EXTRASOLAR 


Magnetic  field  interactions  between  exoplanets  and  their  respective  star:  Detecting  and 
measuring  an  exoplanet’s  magnetic  field  is  a  suggested  science  mission  that  could  help 
determine  if  a  planet  is  habitable,  for  magnetic  fields  shield  against  radiation  which  is  necessary 
for  life  to  thrive.  The  emission  of  heat,  hydromagnetic  waves,  and  accelerated  particles  is  an 
effect  of  the  interaction  between  an  exoplanef  s  magnetic  field  and  its  nearby  star;  thus,  these 
effects  can  be  measured  and  analyzed  in  order  to  model  the  observed  exoplanet.  Another  study 
includes  measuring  the  chromospheric  flux,  x-ray  and/or  radio  emissions  of  photospheric 
magnetic  fields. 

Ultraviolet  astronomy  and  radio  astronomy:Further  ultra  violent  studies  of  exoplanets  have  been 
suggested  by  researchers  wishing  to  model  various  aspects  of  exoplanets.  One  aspect  of 
ultraviolet  research  is  the  measurement  of  auroral  and/or  dayglow  emission  by  large  exoplanets. 


5.8.5  SYNTHESIS  IMAGING 


Synthesis  imaging  is  a  technique  performed  by  multiple  satellites/telescopes  where  the  distance 
between  individual  telescopes,  the  time  lag,  and  the  angle  of  the  incoming  signal  are  used  to 
analyze  the  signal.  Synthesis  imaging  is  used  in  visual,  infrared,  ultraviolet  and  radio  astronomy; 
however,  ultraviolet  and  radio  astronomy  missions  are  more  practical  due  the  size  and  mass 
constraints  on  CASTOR.  The  use  of  this  technique  is  suggested  because  it  will  increase  the 
resolution  of  a  targeted  signal.  The  main  idea  is  to  have  CASTOR  act  as  multiple  receivers  in  an 
array.  By  measuring  a  targeted  signal  at  equal  intervals,  creating  a  “grid”,  and  calculating  the 
time  delay  of  the  signals  it  is  possible  to  treat  CASTOR  as  a  static  array  of  satellites. 


5.8.6  CONCLUSION 

Once  research  has  been  completed,  discussions  with  colleagues,  faculty  members,  and 
professionals  in  their  respective  fields  will  commence  to  determine  what  science  mission,  if  any, 
could  be  performed  by  CASTOR.  Then  the  specifics  of  the  mission  will  be  planned  out  to  fit  the 
capabilities  of  the  satellite.  Following  this  stage  design  and  testing  of  instruments  needed  to 
collect  data  will  be  performed.  It  is  important  to  note  that  all  instruments  must  weigh  less  than 

a 

one  kilogram,  contain  a  volume  less  than  10  cm  ,  and  use  at  most  5  watts  of  power.  This  will 
enable  to  add  the  component  to  the  satellite  without  changing  its  overall  mass  or  structure. 

5.9  THERMAL  TEAM  DATA 
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5.9.1  LM19  THERMAL  SENSOR  SPECIFICATION  SHEET 


e* 


i\'«  /  i  o  n  a  l 

Semiconductor 


October  2007 


LM19 

2.4V,  lOpA.  TO-92  Temperature  Sensor 

General  Description 


The  LM1 9  b  a  precision  annkoq  output  CMOS  rr.egraaednr 
cue  5orrponitL.ro  sensor  that  Dooraaoa  evor  a  -56CC  to  ♦ISO1 
C  temperature  range.  The  r  supply  operating  range  s 
♦2.4  V  to  ♦  S.S  V-  The  transfer  functian  c*  LM1 9  is  predomi¬ 
nately  linear,  yal  has  a  slchr  predictable  partook  curvature. 
The  accuracy  of  the  LM19  when  specified  to  a  parobclc 
transfer  funcaor  a  *2.5*0  aft  ar  ambient  temperature  af  ♦30= 
C.  The  temperature  errer  increases  i  nearly  are  reaches  a 
maximum  of  *3.B*C  at  die  tompemiuro  range  extremes.  The 
temperature  range  is  affected  try  the  power  supply  voteage.  At 
a  power  supply  vc tinge  oi  2.7  V  to  5.5  V  the  tempo  raxre 
range  extremes  are  •130aC  and  -55*0.  Decreasing  the  pew 
or  supply  vettage  to  2-4  V  charges  the  regahv©  extreme  to 
-30^0.  white  the  post  bare  remains  at  ♦  1 30*0. 

The  LM '  S's  gjeocent  curron*  a  lass  than  10  uA.  Therefore, 
soh  heating  is  less  dnan  0.02*0  n  stll  air.  Shuxdpwr  capahlry 
for  the  LM'9  is  narinstc  Pec  a  use  ts  inherent  lew  power  con 
sumption  allows  it  to  be  powered  drectfy  from  the  cLput  of 
rrary  logc  gates  or  does  nor  necessitate  shcodowr  at  aft. 

Applications 

■  Celufar  Phonos 

■  Computers 

■  Power  Supply  Modules 

■  Gaoery  Management 


-  FAX  Machines 

■  Printers 

■  NVAC 

■  Disk  Drives 

■  Appliances 

Features 

■  Paced  for  hJI  -55SC  to  - 1 33 'C  range 

■  Aval  able  n  m  JO-92  package 

■  Predictable  curvature  error 

■  Suit  one*  for  remote  opplcotions 

■  UL  Recognized  Component  MJ 

Key  Specifications 

•  Accuracy  of  *3CfC 

■  Accuracy  at  ♦  13ChC  &  -55CC 

■  Power  Suppy  Vofcage  Range 

■  Current  Drain 

■  Ncnlrtearity 

■  CXftput  Impedance 

■  Load  RegJatior 

0  pA  <  lt<  ■♦16  pA 


*2.5  SC  {max} 
*3-5  to  *3.9  :C  (max) 
♦2.4V  to  ♦S.SV 
10  pA  (max) 
*0.«  (typl 
160  Q  (max) 

-2-5  mV  {max) 
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Typical  Application 
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FIGURE  1  Fi4i-Range  Celsius 
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Temperature  (TJ 

T-jpical  VD 

+  130=0 

*303  mV 

+fOO;C 

+675  mV 

+EC'°C 

+313  mV 

+  1515  mV 

+ 1574  m  V 

<j=e 

+ 1363.3  mV 

-SFC 

+2305  mV 

-40“C 

+2313  mV 

+2435  mV 

Connection  Diagram 


TO-32 


itir  ail 

U  U  U 


wnqM  *EW 

See  NS  Package  Number  ZD3A 


Ordering  information 


Order 

Number 

Temperature 

Accuracy 

Temperature 

Range 

NS  Package 
Number 

Derice 

Marking 

Transport  Media 

LM13CIZ 

±3.B=C 

-EoT  !□  +!3G°C 

ZOSA 

LM13CIZ 

Suit 

ww#  ra  I  d  "  a  com 


£ 


5.9.2  ENGINE  THERMAL  ALGORITHM 


%Engine  Thermal  Model  -  Programmed  in  MATLAB 
%%  Constants 

sig  =  5 . 670400*10A-8;  %Stef an-Boltzman  Constant  W/mA2KA4 

e=l ; a=l ; t=0 ; 
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%%  Material  Properties  ( 1 . Emissivity,  2 . Absoptivity,  3. Thermal  Conductivity 
W/mK) 

css  =  [e,  a,  37];  %CastStainlessSteel 

tungsten  =  [.23,  .38,  200]; 

aisi304  =  [e  ,  a,  16]; 

cp  =  [e  ,  a,  1.495];  %CeramicPorcelain 

alloy  =  [.11,  .17,  180];  %6061  Alloy 

silicon  =  [e,  a,  124] ; 

%%  Parts  (1. Material,  2. Thickness  m,  3. Height  m,  4. Top  Area  mA2,  5. Side  Area 
mA2,  6 . Temperature  K) 


%note: Values  set 

as  a  and  e 

are  not 

actual 

values.  The  correct  values  will 

%be 

substituted 

as  soon  as  they  are 

determined . 

bp 

=  [alloy. 

.231,  .006, 

.042,  . 

.004, 

t] 

; 

%Baseplate  note : approximated 

as 

a  disk  with  radius=.231m 

and  height=. 

00  6m 

os 

=  [aisi304. 

.012,  .061, 

.002,  . 

.014, 

t] 

; 

%Outershell  note : approximated 

as 

a  cylinder  with  outer  radius= . 036m,  inner 

radius= . 025m,  height=.061m 

be 

=  [css. 

.025,  .010, 

.121,  . 

.001, 

t] 

; 

%Base  Core 

lm 

=  [tungsten. 

.020,  .012, 

.003,  . 

.002, 

t] 

; 

%Large  Magnet 

Is 

=  [aisi304. 

.017,  .003, 

.002,  . 

.001, 

t] 

; 

%Large  Spacer 

mm 

=  [tungsten. 

.013,  .012, 

.002,  . 

.002, 

t] 

; 

%Medium  Magnet 

ss 

=  [aisi304. 

.010,  .003, 

.002,  . 

.001, 

t] 

; 

%Small  Spacer 

sm 

=  [tungsten. 

.007,  .012, 

.001,  . 

.002, 

t] 

; 

%Small  Magnet 

cic 

=  [cp. 

.003,  .046, 

.0003, . 

.006, 

t] 

; 

%Ceramic  Insulator-Cone 

Section  note : approximated  as 

a  cylinder 

with 

outer  radius= . 021m,  inner 

radius=.018,  height=.046m 

cit 

=  [cp. 

.010,  .003, 

.002,  . 

.001, 

t] 

; 

%Ceramic  Insulator-Top 

Section 

tr 

=  [allloy. 

.008,  .003, 

.002,  . 

.001, 

t] 

; 

%Top  Ring 

pd 

=  [silicon. 

.002,  .002, 

.0001,  . 

.0001 

,  t] 

; 

%Porous  Disc 

o,  q, 
o  o 

Thermal  Sources  W/mA2 

sfh 

=  1414; 

%Solar  Flux 

Hot 

eah 

=  381.78; 

%Earh  Albedo 

Hot 

eih 

=  257; 

%Earth  IR  Hot 

sf  c 

=  1322; 

%Solar  Flux 

Cold 

eac 

=  224.74; 

%Earth  Albedo  Cold 

eic 

=  218; 

%Earth  IR  Cold 

ca 

=  20; 

%Cathode  note: in  Watts 

O.  O 

o  o 

Resitance 

%This  section  currlently  breaks  the  engine  down  into  layers  starting  with 
%the  inside  and  moving  out.  Eventually  this  section  will  be  broken  down 
%and  each  will  be  shown  on  it's  own. 

rl  =  cic  (2) / (cp (3) *cic (5) ) +pd (2) / (sillicon (3) *pd (5) ) ; 
r2  =  (  (cp  (3)  *cit  (5)  ) /cit  (2)  +  (lm  (2 )  /  (tungsten  (3)  *lm  (5)  )  + 
mm (2 ) / ( tungsten ( 3 ) *mm ( 5 ) ) +  sm (2 ) / ( tungsten ( 3 ) *sm ( 5 ) )  + 

Is (2) / (aisi304(3)*ls(5))  +  ss(2)/(aisi304(3)*ss(5)))A(-l))A(-l); 
r2  =  os (2) / (aisi304 (3) *os  (5) ) ; 

%%  Temperatures  K 

%This  section  currlently  breaks  the  engine  down  into  layers  starting  with 
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%the  inside  and  moving  out.  Eventually  this  section  will  be  broken  down 
%and  each  part's  temperature  will  be  shown. 


dTlh  =  ( . 5*os (5) * ( sfh+eah+eih) *aisi304 (2)  +  ca*cp (2) ) * (rl+r2+r3) ; 
%Temperature  difference  between  Layer  1  and  Layer  3  for  hot  case 
dTlc  =  ( . 5*os (5) * (sfc+eac+eic) *aisi304 (2)  +  ca*cp (2) ) * (rl+r2+r3) ; 
%Temperature  difference  between  Layer  1  and  Layer  3  for  hot  case 


T1  =  (ca/ (cic ( 5 ) *cp (2 ) *sig) ) A . 25 ;  %Temperature  of  inside  layer. 

T3h  =  T1  -  dTlh;  %Temperature  of  outside  layer  for  hot  case. 

T3c  =  T1  -  dTlc;  ITemperature  of  outside  layer  for  cold 

case . 


T2h  =  (Tl/rl  +  T3h/(r2+r3) 
1/ (r2+r3))  %Temperature  of 
T2c  =  (Tl/rl  +  T3c/(r2+r3) 
1/ (r2+r3))  %Temperature  of 


+  . 5*os (5) * (sfh+eah+eih) *aisi304 (2) )/ (1/rl  + 
middle  layer  for  hot  case. 

+  . 5*os  (5) * (sfc+eac+eic) *aisi304 (2) )/ (1/rl  + 
middle  layer  for  cold  case. 


6  LAB  WORK  (LAB  SECTIONS) 
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6.1  ACS  LAB  (D.  DELATTE) 


Laboratory  work  in  Space  Systems  allows  students  to  practice  skills  necessary  for  building  and 
testing  the  satellite.  By  working  on  these  projects,  students  are  able  to  use  the  equipment  in  the 
lab  and  can  gain  experience  with  the  components.  By  having  this  experience,  risk  of  errors  is 
reduced  and  familiarity  is  gained. 


6.1.1  BEACON  FRAME  (D.  DELATTE) 

The  design  of  the  beacon  frame  was  completed  and  the  beacons  were  put  in  place  (not  pictured). 
The  inventory  analysis  from  a  previous  week  was  used  to  determine  the  most  efficient  and  least 
wasteful  use  of  the  available  green  U-bars.  The  air  bearing  is  a  four  by  four  foot  granite  block. 
The  frame  needs  to  clear  the  top  of  CASTOR  on  the  air  bearing,  which  would  be  approximately 
eighty-seven  inches.  Given  these  constraints  and  the  knowledge  that  the  inventory  had  four  eight 
foot  green  U-bars  and  four  ten  foot  U-bars,  it  made  the  most  sense  to  cut  the  ten  foot  pieces  into 
five  foot  segments  and  use  these  for  the  top  and  bottom  pieces  (parallel  to  the  ground). 


FIGURE  6.1-1:  GREEN  BEACON  FRAME 
AROUND  AIR  BEARING 


FIGURE  6.1-2:  CORNER  CONNECTION  OF 
BEACON  FRAME  WITH  DIAGONAL 
SUPPORT  BAR 
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After  the  construction  of  the  main  frame  (pictured  in  figures  above),  five  aluminum  beacon 
holders  were  placed  appropriately  around  the  periphery  of  the  frame.  Three  were  placed  in  a 
vertical  orientation  on  the  top  plane  and  two  were  placed  on  vertical  poles  further  down.  Initially 
there  was  an  issue  getting  the  beacons  to  fin  inside  their  mounts,  but  a  combination  of  using  a 
Dremel  tool  and  loosening  the  screws  holding  the  plate  together  allowed  enough  slack  to  fit  the 
beacons  in  the  mounts.  Measurements  were  taken  of  the  positions  and  these  positions  were  used 
to  create  a  beacons.dat  file  for  SPHERES  so  that  the  air  bearing  can  be  used  in  future  testing. 
The  final  modification  was  to  turn  the  beacons  so  that  they  were  at  35°  from  their  holders  and 
point  directly  into  the  center  where  SPHERES  will  be  on  top  of  the  air  bearing.  This  construction 
and  modification  process  completed  the  lab  for  the  creation  of  the  beacon  frame. 


6.1.2  SPHERES  (D.  DELATTE) 


For  SPHERES,  a  control  was  written  that  would  make  spheres  travel  in  a 
polygon  around  the  glass  table.  Initial  testing  of  the  program  was  moderately 
successful  for  a  first  try.  The  code  did  compile,  SPHERES  was  successfully 
controlled,  and  it  did  move,  but  it  did  not  travel  in  a  perfect  polygon. 

Another  demo  called  “StopAndStare”  focused  on  the  attitude  control  instead  of 
the  position  control.  This  demonstration  showed  the  ability  to  control  the 
attitude  as  well  as  the  gain.  In  the  demo,  SPHERES  was  controlled  to  have  only  10°  of  overshoot 
in  its  attitude.  These  two  demos  were  good  experience  for  when  SPHERES  will  be  used  to  test 
components  on  the  air  bearing. 

The  final  laboratory  work  focused  on  sending  and  receiving  data  between  SPHERES  and  a 
computer  station. 


6.1.3  MAGNETOMETER  (S .  VEGA) 

Component  testing  will  aim  to  prove  that  the  magnetometer  is  capable  of  meeting  accuracy 
requirements.  The  ADCS  requirement  for  attitude  determination  is  within  1°  of  accuracy  in  each 
axis.  To  determine  this  capability,  the  magnetometer  will  be  tested  in  a  magnetic  field  created  by 
a  Helmholtz  coil,  so  that  the  1-axis  magnetic  field  vector  is  known.  When  placed  between  the 
coils,  the  reading  from  the  magnetometer  should  then  confirm  the  known  magnetic  field, 
showing  a  vector  component  of  the  field  in  one  axis.  ADCS  will  also  be  able  to  rotate  the 
magnetometer  to  specified  angles  to  confirm  the  correct  vector  component  measurements  in  each 
axis,  and  determine  to  what  degree  the  magnetometer’s  readings  remain  accurate.  This  next 
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immediate  step  of  this  stage  in  testing  requires  finalization  machining  parts  and  assembly  of  the 
Helmholtz  coil. 


6.1.4  AIR  BEARING  (S .  VEGA) 

Once  this  test  is  completed,  the  next  stage  of  testing  will  be  to  test  the  component  on  the  air 
bearing  test  bed,  using  the  SPHERES  satellite  to  give  a  true  attitude  reading  to  compare  to  the 
reading  from  the  magnetometer.  A  larger  Helmholtz  coil  is  also  being  constructed  around  the  air 
bearing,  such  that  a  similar  test  to  the  tabletop  Helmholtz  coil  test  can  be  run  on  the  air  bearing 
with  greater  degrees  of  freedom  available  to  position  the  magnetometer.  The  goal  is  for  the 
magnetometer  reading  to  be  within  1 0  of  accuracy  in  each  axis.  ACS  will  create  an  estimation 
process  for  the  magnetometer  readings  to  attain  this  accuracy.  The  air  bearing  will  need  to  be 
redesigned  by  this  point  in  testing  in  order  to  accommodate  SPHERES  and  magnetometers  with 
ease  in  new  mounting  points.  A  concept  drawing  has  been  created  as  a  detailed  design  with 
specific  dimensions. 


6. 1 .5  REACTION  WHEEL  (C.  DEVIVERO) 


Closed  loop  reaction  wheel  control  reduces  overall  risks  associated  with  hardware  by  enhancing 
the  air  bearing  capability  to  provide  an  adequate  test  facility.  The  test  facility  can  be  used  by 
CASTOR’S  ACS  components  for  integration  testing  and  performance  verification.  These 
components  need  a  reliable  actuation  system  in  order  to  apply  test  results  to  CASTOR. 

A  closed  loop  Position-Integral  (PI)  controller  shall  be  used  on  the  reaction  wheel  speed  state. 
The  controller  is  of  the  form 


x  =  Ax  +  Bu 

ro  i  oi 


1 

L. 


y  =  Cx  +  Du 
C  =  [0  1  0],D  =  0 


(Equation  1) 

(Equation  2) 

(Equation  3) 

(Equation  4) 
(Equation  5) 
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(Equation  6) 


(Equation  7) 


where  b  is  the  friction  coefficient  of  the  reaction  wheel,  Kt  is  the  current  constant,  R  is  the 
resistance,  L  is  the  inductance,  co  is  the  speed,  i  is  the  current,  and  Vc  is  the  commanded  voltage. 


In  order  for  the  reaction  wheels  to  be  effective,  the  rise  time  of  the  speed  must  be  less  than  the 
time  between  control  loop  executions  (0.050  seconds),  and  there  should  be  no  overshoot  because 
the  braking  system  of  the  reaction  wheels  is  relatively  unpredictable  and  thus  undesirable.  The 
figure  below  shows  the  ideal  performance  of  the  reaction  wheel. 


Time  (sec) 


FIGURE  6.1-3:  IDEAL  REACTION  WHEEL  RESPONSE 


In  Figure  1,  the  y  axis  represents  the  speed  of  the  reaction  wheel  and  the  x  axis  represents  time. 

Figure  2  shows  the  originally  proposed  controller.  While  the  rise  time  is  acceptable,  there  is 
excessive  breaking,  as  well  as  cyclic  breaking  once  in  steady  state. 
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FIGURE  6.1-4:  REACTION  WHEEL  RESPONSE  (WITH  ORIGINAL  CONTROLLER) 


The  Figure  3  shows  the  current  state  of  the  redesigned  controller.  The  rise  time  is  slower  than 
desired,  but  the  breaking  problem  has  been  removed. 


FIGURE  6.1-5:  REACTION  WHEEL  RESPONSE  (WITH  IMPROVED  CONTROLLER) 

Further  work  to  be  done  is  to  reduce  the  system  rise  time,  overshoot,  as  well  as  better 
characterize  the  friction  of  the  reaction  wheel. 


6. 1 .6  HELMHOLTZ  COIL  (N.  CONDUAH) 


To  adequately  test  the  torque  coils  and  magnetometer,  the  presence  of  a  magnetic  field  stronger 
than  the  earth’s  magnetic  field  is  required.  The  ACS  team  thus  decided  to  build  a  Helmholtz  coil 
that  could  be  used  to  provide  a  stronger  magnetic  field  to  tests  against.  Building  an 
Electromagnetic  Lield  Simulator  (EMLS)  would  also  be  beneficial  in  the  long  term  for  the  Space 
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Systems  Lab  since  this  can  be  used  in  numerous  tests  of  magnetic  components  placed  on  the  air 
bearing.  The  following  documents  describes  the  methodology  over  the  semester  used  to  achieve 
this  goal. 

For  CASTOR  the  needed  magnetic  field  is  desired  to  be  in  the  range  of  10-100  times  stronger 
than  the  earth’s  magnetic  field.  The  final  strength  will  be  dependent  on  cost.  To  achieve  this, 
research  was  performed  and  the  idea  of  building  Helmholtz  coils  was  agreed  upon.  The  next  step 
is  thus  to  propose  and  finalize  the  specification  of  the  coils. 

After  some  consideration  it  was  agreed  to  start  off  with  a  1-D  EMFS,  that  is  a  one  Helmholtz 
coil.  For  reasons  of  symmetry  of  the  air  bearing  and  the  availability  of  maneuverability  of  the 
coil  up  and  down  the  air  bearing,  the  coil  will  be  placed  with  the  air  bearing  at  the  center  of  the 
circumference  of  the  coil. 

That  is  along  the  z-axis,  this  would  be  a  -90  degree  rotation  of  the  below  depiction. 

6.2  PROPULSION  LAB  (K.  LOEBNER) 


6.2. 1  ACTIVITIES  OVERVIEW  (K.  LOEBNER) 

The  Propulsion  Laboratory  team  is  responsible  for  one  primary  area  of  investigation  for  the 
Spring  2010  semester.  This  is  to  conduct  efficiency  testing  on  the  Diverging  Cusped  Field 
Thruster  (DCFT)  to  determine  the  highest  efficiency  operating  line  at  a  variety  of  power  levels 
and  flow  rates.  All  additional  and  preparatory  work  is  dedicated  to  this  goal. 


6.2.2  TESTING  EQUIPMENT  (K.  LOEBNER) 
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The  primary  piece  of  testing  equipment  that  is  essential  for  the  successful  execution  of  the 
Efficiency  Testing  is  the  thrust  balance.  The  key  piece  of  equipment  needed  to  execute  the  DCFT 
Efficiency  Test  is  the  thrust  balance.  The  thrust  balance  is  an  apparatus,  depicted  in  Figure  6.2-1: 
Thrust  Balance  below,  consisting  of  a  pendulum,  frame,  and  several  electrical  sensors  and 
actuators. 


FIGURE  6.2-1 :  THRUST  BALANCE 


The  balance  is  controlled  and  operated  by  a  Labview  program  created  by  Randy  Leiter.  Details 
on  how  to  use  the  control  software  are  contained  in  Section  6.2.2. 1.  The  thrust  balance  is 
designed  to  operate  as  follows:  when  a  thrust  is  applied  to  the  upper  plate  by  the  DCFT,  the 
entire  pendulum  rotates  such  that  the  top  and  bottom  plate  remain  parallel.  The  bottom  of  the 
pendulum  contains  a  weight  equal  to  that  of  the  DCFT.  A  pendulum  design  of  this  form  is 
preferable  because  it  ensures  that  the  system  remains  in  equilibrium  when  perturbed  from  its  rest 
position,  and  it  is  far  less  expensive  than  an  electronic  scale  of  the  requisite  sensitivity.  The  top 
and  bottom  plates  are  held  parallel  and  horizontal  using  four  precision -machined  bearings  at  both 
the  upper  and  lower  plate,  and  the  entire  pendulum  rotates  about  another  four  bearings  at  the 
centerline.  These  high  precision  parts  require  no  lubricant,  so  they  are  safe  for  use  in  a  vacuum. 
They  are  also  essentially  frictionless,  which  means  they  contribute  a  negligible  amount  to  the 
overall  system  stiffness,  easing  calibration. 
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Measurements  are  recorded  as  follows:  A  thrust  causes  the  balance  to  move  relative  to  its 
equilibrium  state.  The  position  change  is  recorded  as  a  voltage  by  a  linear  variable  differential 
transformer  (LVDT)  at  the  pivot  point  and  sent  back  to  the  control  software,  which  determines 
the  displacement  and  then  applies  a  voltage  to  the  primary  voice  coil,  which  is  an 
electromagnetic  actuator  located  on  the  thrust  balance  that  applies  a  force  which  restores  the 
pendulum  to  a  neutral  position.  This  process  is  governed  by  a  PI  control  loop  operating  at 
relatively  high  frequency,  so  in  practice  the  balance  will  be  significantly  displaced  while 
experiencing  a  thrust.  The  voltage  necessary  to  restore  the  pendulum  to  its  original  position 
corresponds  directly  to  a  thrust  value. 

Before  the  thrust  balance  can  be  placed  in  the  chamber,  it  must  undergo  a  cleaning  procedure  to 
prevent  it  from  causing  excess  contamination.  The  cleaning  procedure  is  as  follows: 

1)  Disassemble  the  thrust  balance  in  its  entirety.  All  fasteners  must  be  removed,  and 
placed  in  the  sonic  cleaning  system  for  8-10  minutes. 

2)  Any  metal  components  too  large  to  be  placed  in  the  sonic  cleaner  must  be  wiped 
down  on  all  surfaces  with  acetone  to  remove  any  robust  residues,  such  as  ink  or 
adhesive.  **Note:  non-metal  components  such  as  nylon  washers  should  NOT  be 
cleaned  with  acetone,  as  it  could  dissolve  them. 

3)  All  components  must  then  be  wiped  down  with  isopropyl  alcohol  to  remove  any 
soap,  acetone,  or  other  residues. 

4)  The  thrust  balance  must  then  be  reassembled,  using  tools  that  have  been  cleaned 
using  the  same  procedure  outlined  above  in  steps  2  and  3.  **Note:  all  cleaned 
components  should  remain  on  the  laminar  flow  bench  when  not  specifically  in  use  in 
order  to  maintain  their  decontaminated  state. 

In  order  to  obtain  accurate  data  from  the  thrust  balance  during  testing,  it  must  to  be  calibrated 
after  being  placed  in  the  vacuum  chamber  with  the  thruster  mounted  to  it  and  connected  to  the 
Xenon  feed  lines.  This  is  because  the  experimental  setup,  when  fully  operational,  will  cause  a 
slight  offset  in  the  position  of  the  thrust  balance  and  the  stiffness  of  the  system.  Thus,  the 
secondary  voice  coil  must  be  used  to  return  the  thrust  balance  to  zero  displacement,  and  then  a 
calibration  curve  must  be  created  corresponding  to  how  the  thrust  balance  responds  to  the 
stiffness  of  that  particular  configuration. 

In  the  configuration  typically  used  for  prior  testing  of  the  DCFT,  heavy  steel  flex  hoses  were 
used  to  deliver  Xenon  to  the  thruster  anode  and  cathode.  These  hoses  were  too  stiff  for  use  with 
the  thrust  balance,  so  Teflon  tubing  was  used  instead.  However,  if  left  hanging  from  the  rear  of 
the  thruster,  the  weight  of  the  feed  lines  would  displace  the  thrust  balance  to  such  a  degree  that 
data  collection  would  not  be  possible.  Therefore,  a  method  of  suspending  the  Xenon  feed  lines 
and  cathode  wiring  from  the  ceiling  of  the  vacuum  chamber  was  devised  to  mitigate  that  effect. 
By  hanging  all  thruster  connections  from  two  hooks  located  directly  above  the  thrust  balance, 
they  displace  the  thrust  balance  a  small  enough  amount  that  it  is  possible  to  correct  it  using  the 
secondary  voice  coil.  Using  the  Lab  View  software,  the  power  delivered  to  the  secondary  voice 
coil  is  adjusted  until  the  LVDT  reads  zero  displacement,  and  then  calibration  can  begin. 

In  order  to  calibrate  the  balance  inside  the  chamber,  the  calibration  rig  is  placed  at  the  edge  of 
the  chamber  such  that  calibration  weights  can  hang  down  outside  while  exerting  a  force  on  the 
thrust  balance  within.  The  calibration  weights  apply  a  known  force,  and  using  the  LabView 
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software  we  measure  the  voltage  delivered  to  the  primary  voice  coil  in  order  to  counteract  that 
known  weight,  taking  5-10  data  points  at  each  weight  increment.  By  following  this  procedure 
over  the  range  of  thrust-force  values  we  expect  to  achieve,  we  can  generate  a  linear  fit  to  the  data 
as  shown  in  Figure  2  below.  In  this  figure,  the  x-axis  represents  a  non-dimensional  percentage  of 
the  possible  resistance  the  voice  coil  can  provide,  and  the  y-axis  represents  the  force  in  milli- 
Newtons. 


♦  Calibration 
Data 


FIGURE  6.2-2:  MILLI-NEWTONS  VS.  %  FORCE  APPLIED 


Using  this  linear  relationship  derived  from  the  calibration,  the  data  from  the  thrust  balance  can  be 
mapped  to  actual  thrust  values,  and  the  DCFT  efficiency  can  thus  be  calculated. 

6.2.2. 1  THRUST  BALANCE  CONTROL  SOFTWARE  GUIDE 

Hardware  Setup: 

1)  Parts  required: 

■  DCF  Thrust  Balance 

■  Control  Box 

■  9  pin  vacuum  ready  cable 

■  9  pin  cable 

■  Power  cord  for  control  box 

■  USB  cable 

2)  Connect  the  vacuum  ready  9  pin  cable  to  the  9  pin  connector  on  the  thrust  balance. 

3)  Connect  the  other  end  of  the  vacuum  cable  to  the  ordinary  9  pin  cable.  DO  NOT  connect 
the  9  pin  cable  to  the  control  box  yet 

4)  Connect  the  power  cord  to  the  control  box  and  to  a  wall  socket.  DO  NOT  turn  on  the 
control  box  yet. 

5)  Connect  the  usb  cable  to  the  computer. 
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Diagnostic  Steps: 

1)  Connect  the  DAQ  card  to  the  computer  through  the  usb  cable.  Do  NOT  turn  on  the 
control  box. 

2)  Open  the  “Measurements  &  Automation  Explorer”  by  double  clicking  its  icon  on  the 
desktop 

3)  Under  the  toolbar  on  the  left,  expand  “Devices  and  Interfaces” 

•  Expand  “NI-DAQmx  Devices” 

•  Select  USB  6009  Dev  3  (if  the  computer  sees  the  DAQ  card  it  will  be  in  green) 
and  click  on  the  button  that  says  “test  panel”  (see  Figure  6.2-3) 


FIGURE  6.2-3:  DIAGNOSTIC 

4)  While  keeping  the  control  box  switch  in  the  “off’  direction  and  with  no  connection  to  the 
thrust  balance: 

•  Select  the  Analog  Output  Tab,  set  the  channel  to  “aoO”,  and  set  the  voltage  to 
2.5V.  Click  the  update  button. 

•  Go  back  to  the  Analog  Input  tab  and  set  the  following: 

■  Channel  Name-  ai2 

■  Mode-  continuous 

■  Rate-  10,000  Hz 

•  Click  the  Start  button  and  verify  that  the  DAQ  card  is  sending  a  2.5V  signal  as 
expected  (a  small  60Hz  oscillation  may  be  present,  but  it  will  have  a  small 
voltage).  Repeat  by  setting  the  voltage  to  0V  and  5V.  This  will  confirm  that  the 
DAQ  card  is  working  as  expected.  See  Figure  6.2-4. 
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FIGURE  6.2-4:  GUI 

5)  Now  that  the  DAQ  card  is  working  as  expected,  the  amplifying  circuits  will  be  tested. 
First,  go  to  the  analog  output  tab. 

•  Go  to  channel  “aoO”,  adjust  the  voltage  to  2.5V  and  click  update.  Go  to  channel 
“aol”  and  adjust  the  voltage  to  2.5V  and  click  update  as  well. 

6)  Now  connect  the  9  pin  cable  to  the  box  and  turn  the  power  to  the  control  box  on  by 
flipping  the  switch  to  the  “on”  position. 

•  On  the  analog  input  tab,  hit  the  stop  button  and  change  the  channel  name  to  “ail”. 
This  channel  monitors  the  voltage  coming  out  of  the  first  amplifying  circuit.  Go 
ahead  and  click  start. 

•  Now  go  to  the  analog  output  tab.  Make  sure  to  select  channel  “aoO”.  Set  the 
voltage  to  5.0V  and  click  update.  You  should  see  the  voice  coil  pull  or  push  the 
pendulum  thrust  stand  slightly. 

•  Go  back  to  the  analog  input  tab  and  verify  the  voltage  is  no  longer  0V.  It  should 
be  about  0.7  or  0.8V. 

•  Go  back  to  the  analog  output  tab  and  set  the  voltage  to  0V  (and  click  update).  You 
should  see  the  voice  coil  move  the  stand  in  the  opposite  direction  this  time. 

•  Go  back  to  the  analog  input  tab  and  verify  the  voltage  is  now  around  -0.7  to  - 
0.8V. 

•  Go  back  to  the  analog  output  tab  and  set  the  voltage  back  to  2.5V. 

•  The  first  amplifying  circuit  and  voice  coil  are  working  appropriately.  Now  repeat 
these  steps  for  the  output  channel  “aol”  and  input  channel  “ai3”  to  verify  the 
second  amplifying  circuit  and  voice  coil  are  also  working. 

7)  The  next  set  of  steps  will  verify  the  LVDT  is  working  appropriately. 

•  On  the  analog  input  tab,  set  the  channel  name  to  “aiO”  and  click  start.  This 
channel  monitors  the  voltage  signal  coming  from  the  LVDT. 
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•  Simply  tab  the  balance  so  that  it  oscillates  slightly  and  you  should  see  the  signal 
fluctuate  (see  Figure  6.2-5). _ 


FIGURE  6.2-5:  MONITOR  LVDT 

•  When  the  balance  is  settled,  the  LVDT  should  be  reading  as  close  to  0V  as 
possible  (the  neutral  balance  reading).  If  the  LVDT  is  not  reading  close  to  0V 
when  the  balance  is  still,  adjust  the  LVDT  by  loosening  the  screw  that  holds  it  in 
place  and  move  it  appropriately. 

8)  The  diagnostic  steps  are  now  complete.  The  control  box,  LVDT,  and  both  voice  coils  are 
now  working  as  they  should.  Close  the  Measurement  &  Automation  Explorer. 

Operation  Steps: 

1)  Go  to  start,  search,  files  and  folders.  Search  for  the  VI  file  called  MIT-SPL  Thrust 
Balance-5 

2)  Open  the  program.  You  should  see  the  screen  indicated  in  Figure  6.2-6. 
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MIT-SPL  Thrust  Balance-6. vi  Front  Panel  on  MIT-SPL  Thrust  Balance. Ivproj/My  Computer  * 


File  Edit  View  Project  Operate  Tools  Window  Help 

13pMppjlcation^ont^^^J^^J^^J|jgj^^C^^ 


BE)® 


FIGURE  6.2-6:  SPL  THRUST  BALANCE 

3)  First  the  DAQ  card  needs  to  be  configured.  Select  the  tab  which  reads  “DAQ  Config.”. 
•  For  the  analog  input  channels,  select  aiO  (LVDT),  ail  (first  voice  coil),  and  ai3 
(second  voice  coil),  (see  Figure  6.2-7) 


FIGURE  6.2-7:  CONFIGURING  DAQ  CARD 

•  For  the  analog  output  channels,  select  aoO  (first  voice  coil)  and  aol  (second  voice 
coil),  (see  Figure  6.2-8) 
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MIT-SPl  Thrust  Balance.lvproi/My  Computer  |  < 


FIGURE  6.2-8:  ANALOG  OUTPUT  CHANNELS 


4)  Now  go  to  the  manual  control  tab. 

•  Turn  the  PID  control  off.  You  will  know  that  it  is  off  when  the  button  is  red. 
Figure  6.2-9) 


(see 


FIGURE  6.2-9:  TURN  PID  OFF 

5)  Now  the  program  is  ready  to  start.  Make  sure  the  manual  voltage  control  is  set  to  2.5V 
and  select  the  run  button  (the  arrow  button  just  below  the  view  menu). 

•  Select  the  LVDT  position  tab.  The  position  should  be  at  0  for  2.5V.  If  it  is  not, 
some  adjustment  of  the  LVDT  may  need  to  be  made.  See  Figure  6.2-10. 
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FIGURE  6.2-10:  LVDT  POSITION  TAB 

•  Now  go  to  the  System  Response  &  PID  Feedback  Tab.  You  will  see  a  series  of 
lines  on  this  graph 

■  The  white  line  is  the  LVDT  position. 

■  The  green  line  is  the  set  point. 

■  The  red  line  is  the  power  the  PID  software  is  commanding  to  the 
voice  coil. 

•  The  computer  will  work  to  match  the  white  line  with  the  green  line. 

6)  Turn  the  PID  control  on  (button  should  now  be  green).  Allow  the  system  to  settle  and 
reach  steady  state.  Baseline  readings  of  the  thrust  force  should  be  taken  at  this  point  and 
subtracted  from  the  data  later. 

7)  Apply  a  force  to  the  balance.  First  the  white  line  which  represents  the  LVDT  signal  will 
begin  to  move  away  from  0.  Next,  the  red  line  (power  to  the  voice  coil)  will  begin  to 
move  away  from  zero  as  well  (power  being  sent  to  the  voice  coil)  and  the  LVDT  signal 
(white  line)  will  slowly  move  back  to  the  green  line.  See  figure  below.  Eventually,  the 
system  will  reach  steady  state,  with  the  red  line  offset  from  0  by  a  certain  amount  (this  is 
the  thrust  force)  and  the  white  line  will  sit  on  top  of  the  green  line.  See  Figure  6.2-1 1. 
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FIGURE  6.2-1 1 :  LVDT  FORCE  BALANCE 


6.2.3  DCFT  EFFICIENCY  TESTING  (K.  CHOU) 

As  of  the  end  of  Spring  2010,  the  Propulsion  Laboratory  Team  has  completed  the  first  round  of 
data  collection.  Further  testing  will  determine  the  accuracy  of  the  first  data  set  and  obtain  higher 
resolution  information. 


6.2.3. 1  DATA  ANALYSIS 

After  analyzing  the  first  data  set,  correlations  between  the  different  state  variables  can  be  made. 
Of  interest  are  the  correlations  between:  anode  power  and  thrust,  anode  power  and  efficiency, 
and  thrust  and  efficiency.  The  main  equation  during  this  testing  is: 

Fz 


From  the  plot  of  anode  power  and  thrust,  a  direct  correlation  can  be  made  between  the  two 
variables. 


16.83  CASTOR  Design  Document 


Page  295 


April  23,  2010 


Anode  Power  vs.  Thrust 
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FIGURE  6.2-12:  ANODE  POWER  VS.  THRUST 


Figure  6.2-12  shows  that  as  the  anode  power  increases,  the  thrust  produced  increases  as  well,  as 
can  be  explained  from  Equation  1  if  rearranged  to  solve  for  thrust: 

F  =  ^  2rjPm 

The  next  relation  of  importance  is  between  anode  power  and  efficiency.  Looking  at  Equation  1, 
it  can  be  determined  that  an  increase  in  power  will  decrease  efficiency.  This  is  confirmed  in 
Figure  6.2-13,  shown  below: 
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FIGURE  6.2-13:  ANODE  POWER  VS.  EFFICIENCY 
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Lastly,  it  is  important  to  determine  the  relation  between  thrust  and  efficiency.  It  can  be  seen  in 
Equation  1  that  an  increase  in  thrust  will  produce  a  decrease  in  efficiency. 
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FIGURE  6.2-14:  THRUST  VS.  EFFICIENCY 


From  Figure  6.2-14,  it  is  difficult  to  determine  this  relation,  but  if  the  outliers  at  (6.197,  0.413) 
and  (6.364,  0.426)  are  not  taken  into  consideration,  it  can  be  seen  that  an  increase  in  thrust  will 
produce  a  decrease  in  efficiency. 

Because  anode  power  influences  efficiency  and  thrust  in  opposite  ways,  it  is  crucial  to  determine 
how  much  thrust  or  efficiency  to  give  up.  If  a  large  amount  of  power  is  provided,  the  DCFT  will 
provide  higher  thrust  but  have  lower  efficiency.  However,  if  a  smaller  amount  of  power  is 
provided,  the  DCFT  will  have  a  lower  thrust  but  higher  efficiency. 

Further  DCFT  testing  will  provide  more  data  that  allows  for  the  determination  of  power  levels 
with  optimal  thrust  and  efficiency.  After  this  testing  has  been  performed,  DCFT  testing  with 
varying  fuel  mass  flow  rates  will  be  executed  in  a  similar  manner  to  power  level  testing  to 
determine  the  optimal  fuel  mass  flow  rate.  With  the  information  received  from  power  and  fuel 
mass  flow  rate  testing,  the  power  and  fuel  mass  flow  rate  setting  can  be  determined  that  allows 
for  DCFT  peak  performance. 
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Characteristics  of  the  coil  are  specified  using  the  following  field  strength  equation. 

-  -  sr  * 

where 

po  is  the  permeability  of  free  space  1.26  x  10-6  (Tm/A  ),  n  is  the  number  of  turns  of  wire  in  each 
coil,  I  is  the  current  in  A  flowing  through  each  coil  and  R  is  in  meters 

The  magnetic  field  strength  is  desired  to  be  about  10-100  times  stronger  than  the  earths  magnetic 
field.  Earths  magnetic  field  ranges  between  30  microteslas  and  60  microteslas  however  a  value 
of  50  microteslas  was  used  for  calculations.  For  reference  100  times  the  strength  of  the  earths 
magnetic  field  would  is  about  the  strength  of  a  refrigerator  magnet. 

Thus  the  need  for  specific  values  of  current(I),  number  of  tums(n),  type  of  coil  and  cost  thus 
became  apparent  to  finalize  a  design. 


To  make  this  assessment  I  created  a  matlab  script  that  would  take  the  radius  of  the  coil,  current, 
field  strength  and  wire  gauge  as  inputs.  It  would  then  produce  the  number  of  turns  needed,  total 
length  of  each  coil  and  power. 
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Below  are  some  simple  combinations  explored,  with  a  radius  of  2.5  feet  for  the  coil  which  gives 

9 

an  area  of  about  1 .8241m  and  a  perimeter  of  4.787  m. 

TABLE  6.2-1:  HELMHOLTS  COIL  PARAMETER  TEST  RESULTS  1 


Strength 

Desired 

/Earth 

Mag 

Field 

Earth  Mag 
Field 
Strength  / 
microteslas 

Current  / 
A 

Wire 

Gauge 

#  of 

turns 

Total 

length/km 

Power/ 

Watts 

Cost/~$ 

(from 

reliable 

vendor) 

100 

3*10° 

10 

11 

305 

1.75 

724.39 

- 

100 

6*10  3 

10 

11 

610 

3.51 

1448.8 

- 

100 

5*10~3 

10 

11 

508 

2.92 

1207.3 

- 

10 

5*10'5 

5 

14 

102 

0.58 

120.97 

474 

10 

5*10  ^ 

2.5 

17 

203 

1.17 

121.3 

- 

10 

5*10'3 

1.5 

20 

339 

1.95 

145.9 

362 

10 

5*10~3 

1 

21 

508 

2.92 

122.6 

- 

10 

5*10'3 

0.5 

24 

1017 

5.84 

122.98 

550 

10 

5*10'3 

0.25 

27 

2034 

11.68 

123.29 

- 

Depending  on  the  value  of  current  used  the  optimal  gauge  of  wire  was  used  to  reduce  the  amount 
of  resistance  in  the  coil. 

The  idea  was  to  try  and  obtain  the  smallest  amount  of  current  and  use  greater  values  for  voltage 
since  the  power  supply  is  not  greatly  limited.  Also  costs  of  coils  with  a  value  imply  that  the 
current  vendor  did  not  provide  the  gauge  of  wire  specified.  However  the  order  of  the  cost  may  be 
estimated  from  the  scenarios  surrounding  it.  This  may  imply  that  our  final  choice  may  have  to  be 
edited  in  terms  of  gauge  to  ensure  the  vendor  can  provide  them. 

From  the  options  covered,  a  Helmholtz  coil  of  5  A,  102  turns  seems  to  be  the  most  viable  option. 

Another  set  of  calculations  were  performed  after  realizing  the  frame  around  the  air  bearing 
would  put  a  dimensional  limit  on  the  coils  radius.  Thus  a  coil  with  a  radius  of  3  feet  for  the  coil 
which  gives  an  area  of  about  2.6268  m  and  a  perimeter  of  5.745m 
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TABLE  6.2-2  -  HELMHOLTZ  COIL  PARAMETER  TEST  RESULTS  2 


Strength 

Desired 

/Earth 

Mag 

Field 

Earth  Mag 
Field 
Strength  / 
microteslas 

Current  / 

A 

Wire 

Gauge 

#  of 

turns 

Total 

length/km 

Power/ 

Watts 

Cost/~$ 

(from 

reliable 

vendor) 

10 

5UCT3 

5 

14 

68 

0.26 

53.76 

209 

10 

5*10'5 

2.5 

17 

136 

0.52 

53.91 

- 

10 

5U0'5 

1.5 

20 

226 

0.87 

64.83 

204 

10 

5UCT5 

1 

21 

339 

1.30 

54.51 

- 

10 

sno-5 

0.5 

24 

678 

2.60 

54.66 

244 

10 

5UCT5 

0.25 

27 

1356 

5.19 

54.8 

- 

With  these  additional  calculations  we  realize  that  reducing  the  radius  of  the  coil  tends  to  decrease 
a  lot  of  the  other  costly  variables.  From  the  options  in  the  second  table  a  current  of  about  2.5  A, 
using  a  17  gauge  wire,  with  a  total  of  136  turns  and  a  power  rating  of  53  watts  seems  to  be  a 
balance  of  both  cost  and  yield. 


The  next  stage  for  action  in  terms  of  specifications,  is  to  consider  our  resources  and  judge  what 
costs  we  can  incur,  and  what  voltages  can  be  provided  easily  and  safely.  These  will  help  finalize 
the  specifications  of  the  helmholtz  coil. 


Like  any  good  process  refining  and  checking  achieved  measures  is  very  important.  As  such  the 
code  for  optimization  of  parameters  was  revised.  This  time  focus  was  given  to  current  as  the 
deciding  factor.  Together  with  the  desired  field  strength  all  other  parameters  such  as  gauge, 
number  of  turns,  total  length  of  coil,  total  resistance,  power  and  the  actual  field  strength  resultant 
could  be  calculated.  Notably  we  will  most  likely  be  making  use  of  a  power  supply  plugged  into  a 
mains  socket  and  thus  a  maximum  power  rating  of  about  120W  would  be  applied.  Also  the 
power  supply  in  question  has  an  upper  bound  of  40V.  Thus  setting  a  unit  current  of  1 .73  amps. 


Using  this  methodology  the  following  results  were  produced  considering  0-12  Amps. 
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FIGURE  6.2-15:  HELMHOLTS  COIL  PARAMETER  OPTIMISATION:  CURRENT  VS  POWER 


Here  we  see  that  at  the  max  power  value  the  current  is  about  9A. 
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FIGURE  6.2-16:  HELMHOLTS  COIL  PARAMETER  OPTIMISATION:  CURRENT  VS  ORDERS  OF  EARTH 

MAG  FIELD 


Interestingly  we  can  see  that  the  variation  converges  to  a  value  of  ~  7 1  times  the  earths  magnetic 
field  at  about  6A. 

In  my  previous  portfolio  I  presented  5A  as  a  viable  option.  This  gives  1016.9  turn,  a  total  length 
of  5.8426km,  a  total  resistance  of  48.3886  ohms,  a  power  reading  of  33.0657W  and  a  magnetic 
field  strength  ~  60  times  that  of  earths. 

Similarly,  a  current  of  1.7A  gives  2991  turns,  17.1km,  285.4  ohms,  5.6056  W  and  17.73  time  the 
earth  strength. 

Given  the  results  from  the  previous  iterations  and  the  cut  off  of  true  magnetic  field  strength 
6amps  may  be  a  viable  specification  to  consider  when  a  higher  field  strength  is  desired.  For  the 
lower  field  strength  roughly  1,5  amps  should  be  sufficient. 

Eventually  it  will  be  the  ACS  budget  that  will  decide  how  much  we  can  spend  and  thus  how 
much  wire  can  be  purchased. 

The  following  additional  graphs  may  also  provide  insightfulness  in  deciding  the  final  parameters. 
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FIGURE  6.2-17:  HELMHOLTS  COIL  PARAMETER  OPTIMISATION:  CURRENT  VS  LENGTH 
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FIGURE  6.2-19:  HELMHOLTS  COIL  PARAMETER  OPTIMISATION:  CURRENT  VS  NUMBER  OF  TURNS 
Finally  a  table  of  results  is  presented  below,  allowing  for  simpler  comparison. 


TABLE  6.2-3:  RESULTS 


Current/A 

Gauge/ 

AWG 

#of 

Turns 

Length 
of  coil/ 

km 

Resistance 

Power/ 

Watts 

Strength  of 
Magnetic 
Field/EMG 
Strength 

0.5 

24 

10169 

58.43 

4919.3 

0.325 

3.4991 

1 

21 

5084.7 

29.21 

1226.5 

1.304 

7.017 

1.5 

20 

3389.4 

19.47 

648.37 

2.46 

8.85 

2 

17 

2542.3 

14.6 

242.6 

6.59 

17.73 

2.5 

17 

2033.9 

11.69 

194.09 

8.24 

17.73 

3 

14 

1694.9 

9.74 

80.65 

19.84 

35.58 

3.5 

14 

1425.8 

8.37 

69.13 

23.15 

35.58 

4 

14 

1271.2 

7.3 

60.49 

26.45 

35.58 

4.5 

14 

1129.9 

6.49 

53.76 

29.78 

35.58 

5 

14 

1016.9 

5.84 

48.38 

33.06 

35.58 

5.5 

14 

924.84 

5.31 

43.99 

36.37 

35.58 

6 

11 

847.44 

4.868 

20.12 

79.515 

71.287 
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The  above  values  however  are  rather  large  in  terms  of  length  of  coil.  As  such  the  ACS  team  will 
access  the  validity  of  the  calculations  before  finalizing  the  specification. 


Whiles  this  is  being  finalized  it  is  possible  to  go  ahead  and  consider  the  structure  of  the  EMFS. 
Considering  questions  like,  what  will  the  coil  be  wound  around;  should  the  twin  coils  be 
connected  and  if  so  how;  how  will  the  coils  be  attached  to  the  frame?  The  answer  to  all  these 
questions  will  mark  the  final  parameters  needed  to  conclude  on  the  EMFS  design. 


Construction  Issues 

I  found  it  important  and  necessary  to  first  explore  possible  issues  of  contention  that  may  be  faced 
before  finalizing  on  a  form  and  plan  of  construction. 


Form  &  Coiling  Issues 

What  kind  of  a  form  and  structure  should  the  final  coil  have?  Considering  that  the  coil  is  to  be 
mounted  around  the  air  bearing  and  to  the  frame  it  may  be  a  good  idea  to  make  it  as  small  as 
possible  and  with  some  sort  of  the  capability  to  be  attached  to  leads  from  the  frame. 

Specifically  what  kind  of  material  should  be  used  to  ensure  the  circle  shape.  Possible  options 
were  aluminum  channels,  plexy  glass  and  no  form  assuming  the  wound  coil  is  structurally  stable. 
Note  that  these  materials  must  be  non-ferrous  materials  t  avoid  any  interaction  with  the  produced 
magnetic  field. 

Exploring  the  aluminum  channel  a  feasible  option  would  be  the  rings,  as  depicted  below  from  - 
www.johnsonrollforming.com 


Rings:  Channel,  Angle  or  Special  Shapes 

(as-  Illustrated) 
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Given  the  above,  the  question  of  how  to  go  about  effectively  wounding  the  coil  becomes 
apparent.  Especially  since  the  number  of  turns  ranges  on  the  order  of  10A2.  After  some 
consideration  and  referencing,  an  easy  and  effective  solution  will  be  to  just  cut  out  a  circular  disk 
of  ply  wood  larger  than  the  needed  6  ft  diameter.  Bolts  can  then  be  placed  along  the 
circumference  of  the  proper  coil  shape.  The  disk  can  then  be  placed  on  a  base  with  a  pin  at  the 
center,  thus  allowing  the  disk  to  spin  and  simultaneously  wind  the  coil.  Zip  ties  or  any  other 
locking  snippets  could  be  used  to  keep  the  collection  of  coils.  This  scenario  saves  time  and 
allows  for  improved  winding.  However  it  assumes  the  coil  is  not  heavily  insulated. 

Thermal  Issues 

Depending  on  the  resistance  produced  by  the  wire  and  the  time,  we  must  consider  whether  there 
would  be  dire  thermal  consequences.  That  is  the  wire  melting,  or  reaching  high  temperatures  to 
significantly  increase  resistance.  Particularly,  the  windings  closest  to  the  center  since  they  will 
build  up  the  most  heat.  We  must  thus  then  see  what  kind  of  thermal  specification  could  be 
established  to  avoid  this,  such  as  not  running  the  simulation  for  longer  than  a  certain  period.  This 
will  inevitably  help  to  decide  on  which  parameters  to  use. 

A  solution  would  be  to  make  use  of  heavily  insulated  wire  such  as  below 


However  this  will  result  in  a  very  bulky  Helmholtz  coils.  The  above  design  has  less  than  50 
turns.  The  Helmholtz  coil  will  have  turns  on  the  order  of  10A2.  Thus  such  heavy  insulation  may 
not  be  feasible  since  we  want  the  coil  to  fit  around  the  air  bearing  but  within  the  frame.  Also 
enamel  coated  wire  may  or  may  not  do  the  job. 

Taking  all  of  this  into  consideration  will  effectively  assist  in  parameter  specification,  as  well  as 
reducing  the  time  spent  in  construction. 


Earth  Magnetic  Field  Simulator!  EMFS)  -  Future  Goals 
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Given  current  accomplishments  the  following  are  the  goals  ACS  has  with  respect  to  the 
Helmholtz  coil. 

•  Finalize  specifications  on  coils  based  on  cost  and  available  resources 

•  Build  Engineering  Model 

•  Propose  and  build  structure  to  mount  to  frame  of  air  bearing 

•  Perform  Tests 


6.3  CODE  (VARIOUS) 

[The  code  may  be  found  in  Section  1.1  of  the  Fileshare  as  ...] 
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